Closed
Bug 911799
Opened 11 years ago
Closed 6 years ago
We need a cross-module manner of finding out which exceptions we are handling
Categories
(Core :: JavaScript Engine, defect)
Core
JavaScript Engine
Tracking
()
RESOLVED
WONTFIX
People
(Reporter: Yoric, Unassigned)
Details
Consider the following code: try { f(); } catch (ex if ex instanceof TypeError) { handleError(ex); } catch (ex if ex instanceof StopIteration) { handleStopIteration(); } At the moment, throwing a TypeError, StopIteration, etc. in f() may or may trigger the expected branch of the try/case depending on whether the error has been thrown from the same compartment. While this is certainly a desirable property, it would be quite useful to have a way to determine whether a TypeError (respectively a StopIteration) has been thrown in f(), e.g. something along the lines of Array.isArray.
![]() |
||
Comment 1•11 years ago
|
||
Posted about this to public-script-coord, though maybe es-discuss is a better forum for it....
Comment 2•11 years ago
|
||
You need another example to motivate this. StopIteration is dead.
Reporter | ||
Comment 3•11 years ago
|
||
(In reply to Mark S. Miller from comment #2) > You need another example to motivate this. StopIteration is dead. Is it? I haven't been informed. Well, regardless of StopIteration, take a look at bug 908955 - we use the .name hack to find out whether an exception is a coding error, so as to report it eagerly. It works-ish, but that's very fragile.
Assignee | ||
Updated•10 years ago
|
Assignee: general → nobody
Comment 4•6 years ago
|
||
A related proposal to ecma-262 has been rejected [1], so let's resolve this stale bug as WONTFIX. [1] "Builtins.typeOf() and Builtins.is()" at https://github.com/tc39/proposals/blob/master/inactive-proposals.md
Status: NEW → RESOLVED
Closed: 6 years ago
Resolution: --- → WONTFIX
You need to log in
before you can comment on or make changes to this bug.
Description
•