Come posso gestire gli errori nelle funzioni [chiuso]

0

Sto programmando un'app Web utilizzando Perl e Dancer. La logica non è banale e voglio separare la logica della pagina web (all'interno dei percorsi di Dancer) dalla logica di business che legge e scrive dal database. La logica aziendale verrà memorizzata in diversi moduli, letti e scritti nel database utilizzando DBIx :: Class.

La mia domanda è: qual è il modo migliore per mantenere la logica DB nei moduli di business logic, ma essere ancora in grado di inviare messaggi che spiegano l'errore in una pagina Web e memorizzare più dettagli dell'errore in un log. Mi piacerebbe una tecnica che funzioni con funzioni annidate.

Ci stavo pensando, ma non ho trovato un chiaro vincitore. Le opzioni possibili potrebbero essere:

  • Rileva tutte le eccezioni all'interno della funzione e restituisce l'array ref con i dati. Se si verifica un errore, il risultato sarebbe undef.

  • Rileva tutte le eccezioni all'interno della funzione e restituisce un riferimento hash. Se non si è verificato un errore, il tasto "ok" sarà uguale a 1. Un dato di ritorno sarebbe simile a questo:

    return ({
            ok => 1,
            data => [
                    {
                            name => 'Alfa',
                            year => 2014,
                    },
                    {
                            name => 'Beta',
                            year => 2015,
                    },
            ], 
    });
    
    • In un caso di errore il valore restituito potrebbe essere qualcosa del tipo:

      return ({
              ok => 0,
              err => 'bussines.deliveries.estimated_date.no_access_dhl',
              err_web => 'No access to DHL site',
      });
      
  • Cattura le eccezioni nel codice Web utilizzando Try :: Tiny;

Modifica 1 : espansione della mia domanda come risposta a Umut Kahramankaptan : Sto solo iniziando con le eccezioni. Nei giorni scorsi ho letto diverse pagine web sulle aspettative in perl e su come gestirle. Cosa dovrebbe innescare un'eccezione? Un'eccezione è causata solo da un errore (non è possibile aprire un file, una divisione da 0 o un database che non risponde) o dovrebbe essere attivato da un'altra causa che blocca l'esecuzione di una funzione?

Per spiegare l'ultima domanda, propongo diversi casi:

  • Una funzione esegue diverse operazioni di lettura e scrittura su un database. Se uno di questi fallisce dovrebbe attivare un'eccezione.

  • Come per la precedente, una funzione deve eseguire diverse operazioni di lettura e scrittura con un database. Se trova che non può continuare la sua sequenza (a causa di qualche logica o valore esistente nel database), dovrebbe in questo caso attivare l'eccezione?

  • Un esempio più semplice potrebbe essere una funzione di accesso. Se il nome utente e la password sono corretti, dovrebbe restituire diversi dati utente. Cosa dovrebbe succedere se fallisce? return undef ? o attivare un'eccezione?

posta celticman 23.11.2015 - 22:08
fonte

1 risposta

3

Preferirei utilizzare una gestione delle eccezioni di stile OO invece di provare a gestire i codici di errore.

Normalmente quando raggiungi un'eccezione, dovrebbe significare che la tua funzione non è più in grado di funzionare e dovrebbe fermarsi. Quindi l'opzione 1 è uno spreco di risorse in un certo senso.

L'opzione 2 porterà più problemi nelle chiamate di funzioni annidate. Penso che l'articolo Gestione delle eccezioni orientate agli oggetti in Perl di Arun Udaya Shankar spieghi la situazione molto bene.

Con l'opzione 3, una volta rilevata un'eccezione, ci si troverà in un blocco di codice dedicato alla gestione di tale eccezione, in cui è possibile eseguire la registrazione, errore logico Web che si verifica uno dopo l'altro. E se hai bisogno di estendere il tuo codice per includere una ulteriore forma di comunicazione, solo il posto che modificerai sarà all'interno della dichiarazione di cattura.

In breve, Try :: Tiny per implementare la gestione delle eccezioni dello stile OO è la mia preferenza.

Risposta a Modifica 1 : spero che mentre stavi leggendo vedessi anche quanto facilmente puoi aumentare le tue eccezioni. Ecco una pagina da c2.com che offre l'uso di Exception Class. Puoi persino lanciare un'eccezione a seconda della tua logica aziendale.

Il trucco è decidere quando la funzione deve smettere di funzionare e tornare al suo ambito di chiamata con un messaggio che indica perché non dovrebbe più essere eseguito. Quindi tutti i tuoi esempi potrebbero essere validi in base a criteri di progettazione. Anche per il framework .Net, la linea guida da MSDN potrebbe darti più chiarezza.

Per finire con uno dei tuoi esempi. hai una funzione di login che restituisce undef o dati utente. Verificherà se non è undef o meno dopo aver chiamato questa funzione. Invece in un blocco try puoi eseguire la funzione di login, e controllerai se rilevi o meno l'eccezione?

    
risposta data 23.11.2015 - 23:44
fonte

Leggi altre domande sui tag