idea: try/catch and "rethrow"...?

Mike Samuel mikesamuel at gmail.com
Tue Feb 1 11:52:45 PST 2011


2011/2/1 Kyle Simpson <getify at gmail.com>:
> ?I have something that annoys me about how JavaScript try/catch error
> handling currently works. Don't get me wrong, I totally understand why it
> works that way, and it makes sense. But having the option to get around that
> behavior would be really nice.
>
> My idea/proposal is illustrated with this gist:
>
> https://gist.github.com/802625
>
> Essentially, what I'm running into is several different use-cases for the
> need to wrap a try/catch around some call, and "observe" if it error'ed or
> not. Notice in the code snippet that I'm "modifying" the error's message
> string before re-throwing it. However, that's only one use-case. I might
> very well not need to modify the error, but simply passively "observe" (ie,
> not interfere with the bubbling up of that error) and for instance do some
> sort of cleanup or other graceful handling, and then pass the error along to
> continue its bubbling.
>
> The reason for not wanting to interfere is in the sense of wanting the
> original error to maintain its original execution context (almost like an
> error propagation "stack" if you will), so that when the browser/engine
> reports the uncaught error, it reports it from the correct origination point
> (source file, line-number, etc).
>
> If you try/catch such an error, and then "re-throw" it, that context is
> lost. I'm not positive, but I'm guessing that perhaps this is intentional
> by-design, and not just a particular implementation detail. If it *is*
> standardized, I'm proposing an alternative/addition. If not, I'm proposing
> we standardize a way to both preserve and explicitly not-preserve (aka,
> override) the original context. For compat reasons, the default would
> certainly stay as it currently is, with my idea being opt-in if the author
> needs it.
>
> Of course, JavaScript doesn't expose the internals like the original context
> source file/line-number/etc (although I kinda wish it would), so for purely
> JavaScript sake it really doesn't matter. But I'm running into this in the
> server-side JavaScript world numerous times, and wishing the engine could
> keep that context. It's also useful for debugging purposes when looking at
> JavaScript errors reported in the browser's error console, for instance.
>
> I'm interested in thoughts on either snippet's approach and the feasibility
> of something like this?

Do these problems go away if the stack trace is grabbed when the
Throwable is constructed, not when it's thrown?

Java does this for java.lang.Throwable and it provides a
fillInStackTrace() method to allow rethrowers to manually reset the
stack trace to the throw point.

Java also allows for stackless exceptions via setStackTrace(new
StackTraceElement[0]) which allows for pre-allocation of
user-exceptions which for pragmatic reasons (imagine throwing an
OutOfMemoryError because you ran out of space allocating the stack
frame) shouldn't include stack.  This mitigates most of the
inefficiency in using exceptions for control flow, and is used by Neal
Gafter in his Java closures proposal to implement break/continue.




>
> --Kyle Simpson
>
>
>
>
> _______________________________________________
> es-discuss mailing list
> es-discuss at mozilla.org
> https://mail.mozilla.org/listinfo/es-discuss
>


More information about the es-discuss mailing list