I agree with Brad but I will add that if you do end up catching `Exception` or another generic throwable, I'd strongly recommend that you add a comment explaining why you're doing so.
On Mon, Aug 31, 2015 at 5:17 PM, Ben Bucksch <[email protected]> wrote: > 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 >
_______________________________________________ mobile-firefox-dev mailing list [email protected] https://mail.mozilla.org/listinfo/mobile-firefox-dev
