?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
In Narwhal, we wrote something like this:
var thrown = true;
try {
// something done that might throw
thrown = false;
} finally {
if (thrown) {
// exception observed but not caught
}
}
If I recall correctly, and I'm sure it's been noticed that I often
don't, this was
On Tue, Feb 1, 2011 at 12:53 PM, Kyle Simpson get...@gmail.com wrote:
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
On Tue, Feb 1, 2011 at 10:53 AM, Kyle Simpson get...@gmail.com wrote:
?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
[Interested bystander 2p.]
The thing you are looking for is common in other advanced dynamic languages
(mostly Lisp derivatives, see
http://en.wikipedia.org/wiki/Exception_handling#Condition_systems). It is the
concept of handling the condition in the context where the condition is
signaled,
Us old geezers have a tendency to repeat ourselves... If you remind me often
enough, perhaps I'll stop. But it _is_ seductive!
On 2011-02-01, at 14:14, Brendan Eich wrote:
Deja vu all over again:
https://mail.mozilla.org/pipermail/es-discuss/2007-March/004076.html
/be
On Feb 1,
2011/2/1 Kyle Simpson get...@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.
?Brendan/all--
I just tested, and the first snippet (just `throw`ing the same error object)
indeed worked as I wanted (preserved original source/line-number context)
in: FF3.6/4, IE9, Saf5, and Op11. It only fails to preserve context in Chr8
(V8).
So, it would seem that my idea is valid
?FYI: There was already a similar bug filed with V8. I updated it to
indicate that I'm still seeing this happen with ReferenceError's.
http://code.google.com/p/v8/issues/detail?id=764
--Kyle
___
es-discuss mailing list
es-discuss@mozilla.org
On Feb 1, 2011, at 11:52 AM, Mike Samuel wrote:
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
2011/2/1 Allen Wirfs-Brock al...@wirfs-brock.com:
On Feb 1, 2011, at 11:52 AM, Mike Samuel wrote:
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()
On Feb 1, 2011, at 1:42 PM, Mike Samuel wrote:
A debugger (or debugger infrastructure) can capture stack trace information
and maintain an association between a stack trace info and specific thrown
objects. Even if the object is thrown multiple times. (BTW, this is
probably a good use
On Feb 1, 2011, at 1:17 PM, Allen Wirfs-Brock wrote:
Also note that stacktrace properties on Error objects is not in the
ECMAScript standard and personally I don't think it should be.
Having implemented SpiderMonkey's Error object 'stack' property as an
extension, I agree.
A debugger (or
On Feb 1, 2011, at 3:57 PM, Brendan Eich wrote:
This can be made quite fast. But IIRC the current JS VMs, which optimize
heavily, still don't go so fast when you add exception-handling to the
profiles. It's rare in web JS.
One would hope that the constructs that will ultimately get
(fixed a couple naming bugs in my looopForIn function.)
On Feb 1, 2011, at 11:52 AM, Mike Samuel wrote:
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
15 matches
Mail list logo
