Gestione dei guasti con Either -> Where is the stacktrace?

Ho sentito da alcune persone che in Scala tendiamo (come altri linguaggi funzionali) a non interrompere il flusso di controllo ... Invece per convenzione restituiamo l'errore in EitherLeft.Gestione dei guasti con Either -> Where is the stacktrace?

Ma come si ottiene la stracktrace da tale eccezione? Per ora ritorno a sinistra una semplice classe di case Error con un codice, un messaggio e una causa (Error). Ma se ho un errore, non riesco a ottenere lo stacktrace. Se la mia applicazione diventa complessa, potrebbe essere difficile trovare il blocco di codice che ha restituito quello Error ... La causa principale è essenziale.

Quindi cosa facciamo in pratica?

dovrei tornare, al posto di un costume Error, il tipo java Exception o Throwable nel mio Left? Qual è la migliore pratica per la gestione delle eccezioni Scala senza perdere informazioni importanti come lo stacktrace e la causa?

fonte

2012-09-16 Sebastien Lorber

Proprio come una nota, nella prossima Scala 2.10 [c'è anche Try] (http://blog.richdougherty.com/2012/06/error-handling-with-scalas-try.html) per la gestione degli errori –

@ om-nom-nom grazie questo sembra davvero bello! –

Suggerirei di utilizzare Either[java.lang.Throwable, A] (dove Throwable consente ancora l'accesso alla traccia dello stack) e (in generale) rendendo i tipi di errore personalizzati estesi java.lang.Exception.

Questa è la pratica usata da Dispatch 0.9, per esempio, dove Either[Throwable, A] utilizzata per rappresentare i calcoli che possono fallire, e il tipo di errore personalizzate simile a questa:

case class StatusCode(code: Int) 
    extends Exception("Unexpected response status: %d".format(code))

s' Validation.fromTryCatch(a: => T)Scalaz 7 restituisce anche un Validation[Throwable, T] , dove Validation equivale approssimativamente allo Either.

fonte

2012-09-16 19:57:46

Direi che sebbene ci siano esempi di incapsulare le eccezioni in una Either, questa è una cosa sciocca da fare in pratica. Se si dispone di uno schema di codifica degli errori, una soluzione ha senso; altrimenti, basta lanciare l'eccezione in modo che quelli più in alto nella catena di chiamate possano gestirli o trasmetterli. –

@rs_atl: Dire che sono bloccato con la possibilità di qualcosa come un 'NumberFormatException' quando si tenta di analizzare una stringa in un numero intero, ad esempio. Entrambe le eccezioni e l'uso di una classe di errore personalizzata o di un wrapper mi sembrano più insignificanti del semplice approccio "O [Throwable, Int]". –

@TravisBrown grazie. È una buona pratica restituire una Sinistra (Lanciabile) invece di una Sinistra (Eccezione)? Dal momento che non dovremmo prendere Throwables comunque. Può portare uno sviluppatore a catturare un errore OutOfMemory per l'esempio no? –

Gestione dei guasti con Either -> Where is the stacktrace?

risposta

Problemi correlati