try { // Some code}catch (SomeException e) { Log.e("MyLib", "Error: " + e.getMessage().toString() );}
toStringpublic String toString()Returns a short description of this throwable. If this Throwable object was created with a non-null detail message string, then the result is the concatenation of three strings:The name of the actual class of this object": " (a colon and a space)The result of the getMessage() method for this objectIf this Throwable object was created with a null detail message string, then the name of the actual class of this object is returned.Overrides:toString in class ObjectReturns:a string representation of this throwable.
1) toString() è di troppo, visto che getMessage() restituisce un oggetto String già di suo
2) basterebbe, secondo la doc ufficiale, stampare e.toString(), che darebbe in output:CitazionetoStringpublic String toString()Returns a short description of this throwable. If this Throwable object was created with a non-null detail message string, then the result is the concatenation of three strings:The name of the actual class of this object": " (a colon and a space)The result of the getMessage() method for this objectIf this Throwable object was created with a null detail message string, then the name of the actual class of this object is returned.Overrides:toString in class ObjectReturns:a string representation of this throwable.Quindi si poteva anche risparmiare la concatenazione di stringhe a mano,
ma... soprattutto....3) sempre secondo la doc ufficiale, getMessage potrebbe ritornare anche null Questo sai che vuol dire? che spesso e volentieri dentro quel catch avviene un NullReferenceException che si porta giù tutta l'applicazione! Simpatico vero?Questo dimostra solo che certa gente usa i try..catch solo ed esclusivamente perchè Eclipse li piazza in automatico, senza realmente capire cosa vuol dire "gestire gli errori di runtime".Oggi zampillo bile da tutti i pori... :angry-screaming:
2) basterebbe, secondo la doc ufficiale, stampare e.toString(), che darebbe in output:
// entry point del threadpublic void run(){ Data d = new Data(); boolean success = false; try { // fai qualcosa di pericoloso //... success = true; } catch ( Exception e ) { if ( mOnErrorListener != null ) mOnErrorListener.onError( new StatusCode( e ) ); else Log.e( e.toString() ); } finally { // cancella eventuali richieste HTTP pending, eventuali thread di lavoro secondari, ecc... } // tutto ok if ( success && mOnSuccessListener != null ) mOnSuccessListener.onSuccess( d );}
Citazione da: "cdimauro"Comunque a volte mi capita di usarle al posto della restituzione di un booleano. Mi ci avete fatto pensare adesso. In un'API di Login sollevo un'eccezione in caso di fallimento, e non faccio niente se è tutto OK. La prossima volta utilizzo un booleano per le due situazioni.Questo è un abuso il fallimento del login non è un caso eccezionale (lo so che lo sai già),
Comunque a volte mi capita di usarle al posto della restituzione di un booleano. Mi ci avete fatto pensare adesso. In un'API di Login sollevo un'eccezione in caso di fallimento, e non faccio niente se è tutto OK. La prossima volta utilizzo un booleano per le due situazioni.
comunque tu che programmi in python potresti utilizzare come fanno molti i multiple return value delle funzioni per la gestione degli errori (anche se non mi piace, meglio una classe a parte per gestire un evento error).
Comunque a tal proposito consiglio Exception Handling: The Case Against di Andrew Black, http://web.cecs.pdx.edu/~black/publicat ... Thesis.pdfPotete saltare a pagina 225 in cui riassume tutto su Conclusion
Citazione da: "cdimauro"Comunque per me le eccezioni rimangono un costrutto utile proprio per migliorare la leggibilità e la manutenibilità del codice. Possiamo chiamarlo zucchero sintattico per risolvere determinati "pattern" di utilizzo del codice, se vogliamo, ma sono una gran comodità.Però il problema è lo stesso di quello del goto, capisco che molte IF nested possono essere un problema, ma dipende molto dal coding style utilizzato.Io sono un maniaco dell'eleganza del codice, deve essere semplice, pulito e mai incasinato. Sia goto che exception non mi sono mai servite.
Comunque per me le eccezioni rimangono un costrutto utile proprio per migliorare la leggibilità e la manutenibilità del codice. Possiamo chiamarlo zucchero sintattico per risolvere determinati "pattern" di utilizzo del codice, se vogliamo, ma sono una gran comodità.
@safe(NoCheck, CheckSID, CheckID, CheckExternalUserIDType, NoCheck)def GetRegisteredUsers(req, SID, in_UserID, in_UserIDType, in_UsersList): MyUserID = DB.Users[ID].Where[ID == in_UserID]() if MyUserID is None: raise UserNotFound UsersList = [User for User in in_UsersList.split(',') if User] if not UsersList: raise EmptyList Fields, Condition = ((ID, EMail), (EMail.In(UsersList), ID != in_UserID)) if in_UserIDType == 'EMail' else ((ID, FaceBookID), (FaceBookID.In(UsersList), ID != in_UserID)) List = DB.Users[Fields].Where[Condition].OrderBy[ID].List() RegisteredUsersList = ('<User ID="%s" Info="%s" />' % (ID, Conv.StringToXMLOnlyEntities(Value)) for ID, Value in List) return '<RegisteredUsers>%s</RegisteredUsers>' % 'n'.join(RegisteredUsersList)
<Error Name="InternalError" AppliesTo="" Value="" Message="%s"> <Function>%s</Function> <Keywords>%s</Keywords> <TraceBack>%s</TraceBack> </Error>
<Error Name="%s" AppliesTo="%s" Value="%s" Message="%s"/>
<Error Name="EmptyList" AppliesTo="in_UsersList" Value="" Message="Empty list"/>
<Error Name="MalformedID" AppliesTo="in_UserID" Value="Pippo" Message="Malformed ID"/>
Una cosa molto più importante di questa roba qui è un meta-linguaggio per i pre e post condition ed invariant, e testare le interfacce come lavoro ultimo del compilatore (o del runtime, se le interfacce sono tipi dinamici)