You are viewing a plain text version of this content. The canonical link for it is here.
Posted to commits@fineract.apache.org by GitBox <gi...@apache.org> on 2020/05/21 10:19:44 UTC

[GitHub] [fineract] vorburger commented on pull request #916: FINERACT-942 Added and Enforced EmptyCatchBlock checkstyle

vorburger commented on pull request #916:
URL: https://github.com/apache/fineract/pull/916#issuecomment-632006602


   > @vorburger I hope this is the correct approach to deal with empty catch blocks :)
   
   Your job here is going to be a little bit more challenging, thus more interesting! :smiling_imp: 
   
   What you are getting into here is kind of related to what I alluded to in FINERACT-932... there are 2 cases: You're finding a number of obvious plain wrong empty `catch` statements. For example, catching a `javax.mail.MessagingException` is most certainly a clear bug! If your code is trying to send out an email, and that fails, probably your SMTP server is fried, or whatever - and you certainly do want an "operator" who supervises error logs (e.g. like I do on https://www.fineract.dev, using https://cloud.google.com/error-reporting) do know about that. E.g. that `GeneralSecurityException` you spotted most likely also fall into this category.
   
   However, for e.g. `EmptyResultDataAccessException` I'm personally not entirely sure yet. What does that exception signal? Presumably Spring is indicating that some JDBC ResultSet was empty, when it should not have been? Is that OK, or a clear indication of a database corruption? That depends on the specific code... But if it is OK and can happen during "normal" execution, then... there is another problem - then some other Spring API which returns an empty list or an Optional or something like that should have been used instead of expecting an exception! Do you know what I mean?
   
   BTW can you write up what I'm explaining here into a follow-up PR to #912 ? :smile: 


----------------------------------------------------------------
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.

For queries about this service, please contact Infrastructure at:
users@infra.apache.org