`rethrow` operator

💡 Ideas
#1

The idea is simple: a rethrow key word to use inside catch blocks. This would cause errors that are re-thrown to be thrown as if from their original location, so as to not disrupt the error stack.

For example:

try {
  // ...
} catch (e) {
  if (!(e instanceof SomeSpecificError)) rethrow e // make it behave as it would have normally

  // ... handle special error ...
}

The idea is that the error would behave exactly as if it was thrown from its original location before try catch would have intercepted it, as if there never were a try catch.

Currently, when we re-throw errors using throw, the stack trace that dev tools shows will not be exactly as where the error originated, but will include the new throw location (can be confusing).

#2

That’s not correct; stack traces are fixed when an error is created; re throwing it has no effect. If it does, file a bug on that browser.

2 Likes
#3

@ljharb the developer tools can only pause where an error is thrown (throw expr), not where the Error instance has been created (new Error)

#4

@JackWorks the developer tools can however pause both in the location where it is thrown the first time (if break on caught exceptions is enabled) and in the location where it is re-thrown (if break on exceptions is enabled).

#5

Dev tools can choose whatever behavior they like; regardless, a stack trace (which is what the OP described) is never generated from throwing - only from creating a new error object.

#6

I suppose it is the devtools behavior that is not ideal. Maybe the spec can address that; that's what the rethrow idea was for. I do see that if I inspect the error.stack I see the original stack. But devtools shows me other stuff based on where an error is re-thrown.

Essentially what I was hoping for is a way to cause the try-catch to behave as if it was never there.

#7

Who's dev-tools are we talking about here?

I tried using the following code sample:

function fn1() {
  try {
    fn2();
  } catch (err) {
    throw err;
  }
}
function fn2() {
  throw new Error('Whoops!');
}
fn1();

In Chrome's REPL, I get the correct stack trace

image

Firefox's REPL works as well:
image

Here's Node's

Uncaught Error: Whoops!
    at fn2 (REPL10:2:9)
    at fn1 (REPL7:3:5)

If I'm using breakpoints in Chrome, I still get the correct callstack in its debugger if I make sure to ask it to "Pause on caught exceptions".

image

1 Like
#8

Hmmm, you're right, nvm, not sure what I saw. Was it always like that? Maybe an async stack threw me off; but that only adds to the stack when expanded, it looks like.

#9

Yea, it’s always been like that afaik.