Utilizzo delle eccezioni come oggetti normali [duplicato]

Question

Utilizzo delle eccezioni come oggetti normali [duplicato]

#1 da (4 voti)

1

Ho viste che gestiscono diversi errori nella mia applicazione. Ad esempio l'errore 404, 403 e così via, dando ai miei errori una presentazione più user-friendly. Per ipotesi, vengono inoltrati in un'eccezione, quindi questo è l'aspetto di un esempio di visualizzazione di gestione degli errori:

<h1>Whooops! An error with code <?=$exception->getCode()?> has occurred.</h1>
<p><?=$exception->getMessage()?></p>

Ma da qualche parte lungo le linee ho incontrato la necessità di visualizzare una determinata vista di errore come solo una parte di una pagina, quindi ho deciso perché non farlo

// somewhere in another view
echo $errorView->render(new \Exception('Message', 403));

La mia domanda è se nel mio caso particolare sia una buona pratica di programmazione lanciare eccezioni? O dovrei gestirlo diversamente da come lo sto gestendo ora?

php exceptions exception-handling

posta php_nub_qq 25.03.2015 - 19:42

fonte

1 risposta

Leggi altre domande sui tag php exceptions exception-handling

Come assicurarsi che il codice pulito sia implementato correttamente? [duplicare] C # / MonoGame - Programmazione di nemici e livelli in file di script esterni

score 4 · Accepted Answer

Hai una situazione in cui si verifica un'eccezione per una ragione o per l'altra. Non ha davvero senso andare avanti ed è necessario iniziare il salvataggio e rendere la pagina di errore web corrispondente (questa è una applicazione Web dopotutto).

Ora, per presentare alcune informazioni all'utente finale, è necessario in qualche modo ottenere alcuni dati in quella pagina di errore. E in tal senso, un'eccezione è un buon posto per mettere quei dati.

Altre opzioni sono convolute dove si cerca di riempire i dati in un contesto di sessione o da qualche parte che è "ovunque tranne l'eccezione". Ma perché non l'eccezione? Può contenere dati (sia esso un messaggio o il tipo di eccezione o qualsiasi altro dato che si sta avvolgendo in altre situazioni) ed è presente quando si esegue il rendering della risposta finale.

L'uso dell'eccezione per conservare questi dati è il posto perfetto per mettere tali informazioni. Lo tiene insieme, lo rende disponibile per le parti dell'applicazione che ne hanno bisogno e mostra chiaramente il suo intento e la sua responsabilità.

Le pagine di errore solo richiedono eccezioni? Questa è una domanda un po 'più complicata. E ciò sembra un po 'imbarazzante in quanto si sta creando un oggetto di eccezione, ma non lo si lancia e invece lo si passa come argomento. E questo ha un sentimento "icky", ma potrebbe essere necessario per altre parti dell'applicazione che non sono presentate qui.

Altre parti dell'applicazione possono comportarsi in modo particolare quando le eccezioni iniziano a fluttuare (come i logger o altri aspetti trasversali che agiscono quando viene creata un'eccezione). Ma, ancora, senza ulteriori informazioni sull'architettura questa è pura speculazione.

Sarei tentato di creare un'interfaccia di un errore (nota che questo è un tipo di mano ondulata qui e potrebbe non essere applicabile a tutti i paradigmi linguistici). Quindi avere un tipo di eccezione specifico implementare questa interfaccia ... insieme a un oggetto non eccezione che lo implementa anche. Quindi inviare l'oggetto Error alla pagina di rendering. Ciò consentirebbe di creare una ErrorException quando necessario, ma anche solo di creare un errore quando non si richiede un'eccezione.