1044109 - Regression: Error thrown by function in JS XPCOM component is shown in error console even if call is wrapped in a try/catch.

Status: RESOLVED WONTFIX

(Core :: XPConnect, defect)

Description

[(inactive) Nihanth Subramanya [:nhnt11]]

In a scenario with two JS components, one tries to call a function the other. The function throws NS_ERROR_NOT_IMPLEMENTED, and even though the call is wrapped in a try/catch, the error is shown in the error console as an uncaught exception.
For more context, please see [1].

This bug was noticed by Instantbird users some time in June.

[1] - https://bugzilla.mozilla.org/show_bug.cgi?id=1019132#c2

Comment 1

[Bobby Holley (:bholley)]

I might take a patch, but in general this stuff is broken enough that we need to fix bug 1044109 before we make any meaningful progress on it.

Comment 2

[Bobby Holley (:bholley)]

(In reply to Bobby Holley (:bholley) from comment #1)
> I might take a patch, but in general this stuff is broken enough that we
> need to fix bug 1044109 before we make any meaningful progress on it.

Er, bug 981187.

Comment 3

[Boris Zbarsky [:bzbarsky]]

Note that this was a purposeful change.  We used to guess-suppress the exception sometimes, but then that led to exceptions that never ever got reported...

Comment 4

[(inactive) Nihanth Subramanya [:nhnt11]]

Just to be clear, the catch {} block is executed, but there is a spurious uncaught error. If I report the error from the catch block, I see /two/ errors in the console: one |uncaught exception: 2147500033| and one (from the catch block) |[Exception... "Method not implemented'Method not implemented' when calling method: [prplIAccount::requestRoomInfo]"  nsresult: "0x80004001 (NS_ERROR_NOT_IMPLEMENTED)"|

Comment 5

[Boris Zbarsky [:bzbarsky]]

Yes, exactly.  The point is the callee has to decide whether to report or not before it knows whether the caller will actually even see the exception, so it has no way to tell whether the exception might get caught in the future.  We were having cases of uncaught exceptions not getting reported as a result, because the callee thought the caller would handle it but the caller wasn't actually JS.

Like Bobby says, bug 981187 will make things here saner, hopefully.

Comment 6

[Boris Zbarsky [:bzbarsky]]

OK, things are saner, but at this point this bug seems like it should be wontfix.  We really just don't know whether we have a JS caller or not at the point when we need to report the exception, so the options are to swallow exceptions when we should not or report even if caught further upstream.  Given that choice, we will do the latter.