Closed
Bug 968214
Opened 11 years ago
Closed 11 years ago
Feature: try / success
Categories
(Core :: JavaScript Engine, defect)
Core
JavaScript Engine
Tracking
()
RESOLVED
INVALID
People
(Reporter: Yoric, Unassigned)
Details
Consider the following pattern:
let foo;
try {
foo = f();
} catch (ex1 if ...) {
// ...
} catch (ex2 if ...) {
// ...
} finally {
close();
}
// Now do something with foo
With an appropriate keyword "success", we could rewrite something almost equivalent as:
try {
f();
} success (foo) {
// Now do something with foo
} catch (ex1 if ...) {
// ...
} catch (ex2 if ...) {
// ...
} finally {
close();
}
This would put the "Now do something with foo" closer to f(), and keep error-handling on the outside, which I believe is more readable.
Reporter | ||
Updated•11 years ago
|
Summary: Feature: try / catch-no-error → Feature: try / success
![]() |
||
Comment 1•11 years ago
|
||
So this differs from this:
try {
let foo = f();
// Now do something with foo
} catch (ex1 if ...) {
// ...
} catch (ex2 if ...) {
// ...
} finally {
close();
}
in that it calls close() before doing the "something" (which would be a bit weird, in the success() setup) and doesn't catch exceptions from the "something"?
Reporter | ||
Comment 2•11 years ago
|
||
Exactly.
Comment 3•11 years ago
|
||
I've occasionally wanted something like this. However, as long as TC39 is chugging along, our JS engine is not taking new language features that aren't standard-track.
Propose it on es-discuss or (better still) talk it over with one of Mozilla's TC39 representatives (Dave Herman, Allen Wirfs-Brock, or Brendan Eich).
I think the part of this that might give them pause will be the use of the block `{ f(); }` as an expression producing a value. What if it's an if-statement in there? and so on.
Status: NEW → RESOLVED
Closed: 11 years ago
Resolution: --- → INVALID
You need to log in
before you can comment on or make changes to this bug.
Description
•