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
_______________________________________________
mobile-firefox-dev mailing list
[email protected]
https://mail.mozilla.org/listinfo/mobile-firefox-dev
