Eccezioni: è una buona pratica?

StackOverflow https://stackoverflow.com/questions/103583

Domanda

Questo è scritto in PHP, ma è in realtà un linguaggio agnostico. 

try
{
    try
    {
        $issue = new DM_Issue($core->db->escape_string(
 Questo è scritto in PHP, ma è in realtà un linguaggio agnostico. 


<*>


 È nidificato provare, catturare i blocchi è una buona pratica da seguire? Sembra un po 'ingombrante solo per una pagina di errore, tuttavia il mio Issaman Datamanager genera un'eccezione se si verifica un errore e lo considero un buon modo per rilevare l'errore. 



 L'eccezione Error_Page è semplicemente un compilatore di pagine di errore. 



 Potrei essere solo pedante, ma pensi che sia un buon modo per segnalare errori e in tal caso puoi suggerire un modo migliore per scrivere questo? 



 Grazie 
GET['issue']));
    }
    catch(DM_Exception $e)
    {
        throw new Error_Page($tpl, ERR_NOT_FOUND, $e->getMessage());
    }
}
catch(Error_Page $e)
{
    die($e);
}

È nidificato provare, catturare i blocchi è una buona pratica da seguire? Sembra un po 'ingombrante solo per una pagina di errore, tuttavia il mio Issaman Datamanager genera un'eccezione se si verifica un errore e lo considero un buon modo per rilevare l'errore.

L'eccezione Error_Page è semplicemente un compilatore di pagine di errore.

Potrei essere solo pedante, ma pensi che sia un buon modo per segnalare errori e in tal caso puoi suggerire un modo migliore per scrivere questo?

Grazie

È stato utile?

Soluzione

Stai usando Eccezioni per la logica della pagina e personalmente penso che non sia una buona cosa. Si dovrebbero usare eccezioni per segnalare quando accadono cose brutte o inattese, non per controllare l'output di una pagina di errore. Se desideri generare una pagina di errore basata su Eccezioni, considera l'utilizzo di set_exception_handler . Eventuali eccezioni non rilevate vengono eseguite con qualsiasi metodo di callback specificato. Tieni presente che ciò non interrompe la "fatalità". di un'eccezione. Dopo che un'eccezione è passata attraverso il callback, l'esecuzione si interromperà normalmente dopo qualsiasi eccezione non rilevata.

Altri suggerimenti

Penso che faresti meglio a non annidare. Se si prevedono più tipi di eccezione, è necessario disporre di più catture. 

try{
  Something();
}
catch( SpecificException se )
{blah();}
catch( AnotherException ae )
{blah();}

L'ideale è catturare le eccezioni al livello che può gestirle. Non prima (perdita di tempo) e non dopo (perdi contesto).

Quindi, se $ tpl e ERR_NOT_FOUND sono informazioni che sono solo " conosciute " vicino alla nuova chiamata DM_Issue, ad esempio perché ci sono altri posti in cui si crea un DM_Issue e si vorrebbe ERR_SOMETHING_ELSE o perché il valore di $ tpl varia, quindi si sta rilevando la prima eccezione nel posto giusto.

Come passare da quel luogo alla morte è un'altra domanda. Un'alternativa sarebbe morire proprio lì. Ma se lo fai, allora non c'è alcuna possibilità per il codice che interviene di fare qualcosa (come cancellare qualcosa in qualche modo o modificare la pagina di errore) dopo l'errore ma prima di uscire. È anche utile disporre di un flusso di controllo esplicito. Quindi penso che tu sia bravo.

Suppongo che il tuo esempio non sia un'applicazione completa: se lo è, probabilmente è inutilmente prolisso e potresti semplicemente morire nella clausola catch DM_Exception. Ma per una vera app approvo il principio di non morire nel bel mezzo del nulla.

A seconda delle tue esigenze, ciò potrebbe andare bene, ma in genere sono piuttosto titubante nel catturare un'eccezione, avvolgere il messaggio in una nuova eccezione e ricominciarlo perché perdi le informazioni sullo stack stack (e potenzialmente altre) dall'eccezione originale nell'eccezione di wrapping. Se sei sicuro che non hai bisogno di tali informazioni quando esamini l'eccezione di wrapping, probabilmente va bene.

Non sono sicuro di PHP ma in es. In C # puoi avere più di un catch-block, quindi non c'è bisogno di combinazioni nidificate di try / catch.

Generalmente credo che la gestione degli errori con try / catch / infine sia sempre di buon senso, anche per mostrare "solo" " una pagina di errore. È un modo chiaro per gestire gli errori ed evitare comportamenti strani in caso di crash.

Non darei un'eccezione al problema non trovato: è uno stato valido di un'applicazione e non è necessaria una traccia dello stack solo per visualizzare un 404.

Quello che devi catturare sono guasti imprevisti, come errori sql - è quando la gestione delle eccezioni è utile. Vorrei cambiare il tuo codice per assomigliare di più a questo: 

try {
    $issue = DM_Issue::fetch($core->db->escape_string(
 Non darei un'eccezione al problema non trovato: è uno stato valido di un'applicazione e non è necessaria una traccia dello stack solo per visualizzare un 404. 



 Quello che devi catturare sono guasti imprevisti, come errori sql - è quando la gestione delle eccezioni è utile. Vorrei cambiare il tuo codice per assomigliare di più a questo: 


<*>GET['issue']));
}
catch (SQLException $e) {
    log_error('SQL Error: DM_Issue::fetch()', $e->get_message());
}
catch (Exception $e) {
    log_error('Exception: DM_Issue::fetch()', $e->get_message());
}

if(!$issue) {
    display_error_page($tpl, ERR_NOT_FOUND);
}
else
{
    // ... do stuff with $issue object.
}

Le eccezioni devono essere utilizzate solo se si verifica un evento potenzialmente dannoso per il sito, come una query del database che non viene eseguita correttamente o che qualcosa non è configurato correttamente. Un buon esempio è che una cache o una directory dei log non è scrivibile dal processo Apache.

L'idea qui è che le eccezioni sono per te, lo sviluppatore, per fermare il codice che può rompere l'intero sito in modo da poterli correggere prima della distribuzione. Sono anche controlli di integrità per assicurarsi che se l'ambiente cambia (ovvero qualcuno modifica le autorizzazioni della cartella cache o cambia lo schema del database) il sito viene arrestato prima che possa danneggiare qualsiasi cosa.

Quindi no; i gestori di cattura nidificati non sono una buona idea. Nelle mie pagine, il mio file index.php racchiude il suo codice in un blocco try ... cache - e se succede qualcosa di brutto controlla se è in produzione o no; e mi invia un'e-mail e visualizza una pagina di errore generica oppure mostra l'errore direttamente sullo schermo.

Ricorda: PHP non è C #. C # è (con l'eccezione (hehe, no pun punito: p) di ASP.net) per le applicazioni che contengono stato - mentre PHP è un linguaggio di script senza stato.

Autorizzato sotto: CC-BY-SA insieme a attribuzione
Non affiliato a StackOverflow
scroll top