Catching generic Exceptions

[Ben Bucksch]

Nicholas Alexander wrote on 01.09.2015 00:34:
> Over in a review [1] for Bug 1191067, sebastian asks the following 
> excellent question:
>
>     ::: mobile/android/base/AccountsHelper.java:127
>     (Diff revision 1)
>     > +            } catch (Exception e) {
>
>     This is not related to these reviews and patches or this line in
>     particular but I've seen us catching generic exceptions in various
>     places. Is this to ensure the callback is triggered at all costs?
>     I'm always afraid that this will silently catch all kinds of
>     unchecked exceptions (e.g. NullPointerException,
>     ClassCastException, ..) in later iterations. Do we have any
>     guidelines in what situations it's okay to do this? Most projects
>     seem to discourage you from doing this.
>
>
> I'll answer from my own perspective, but I'd like to get more comments.
>
> For some context, this code is handling a message from 
> chrome-privileged JavaScript to Java.  The message is expected to be 
> triggered from an add-on -- i.e., I don't control the inputs 
> entirely.  In such contexts -- essentially, message handling -- I 
> never want to fail. Given how hard it can be to handle unchecked 
> Exception-sub classes, and how hard it can be to sanitize input 
> completely, I err on the side of caution.  It would be nice to 
> differentiate "routine mistake" NPEs from "bad input, need more null 
> check" NPEs but I often am not fully confident that I haven't made an 
> error.  In this situation, I blanket catch Exception for safety.
>
> I am not aware of guidelines, expectations, or a style guide for 
> Fennec.  What do others do?  What do others think we should recommend?

I concur with you, Nick.

1. You don't want a JS-orginated exception somewhere high up in the Java 
code where you don't expect this *type* of exception and don't know what 
it is anymore.
2. Higher up, you lack context what to do with it, because you don't 
know anymore what *function* called it and what the code attempted to 
do. You can only say "oops, something went wrong", but you don't know 
*what* went wrong or how to recover.
3. Here, where you called the JS code, you know exactly what went wrong 
and how to recover. Whether there's a parse error in JS code, or a 
memory exhaustion in JS, or a real error: Either way, the JS code you 
called failed and you need to be able to handle that case. If you can 
handle one of these exceptions with certain error handling, chances are 
you can handle the other exceptions with the same error handling code.
4. And yes, err on the side of caution, esp. when crossing language 
borders or contexts.

Ben