[CLJS-449] stack traces for ex-info Created: 23/Dec/12 Updated: 21/Feb/15 Resolved: 21/Feb/15
Currently, ex-info exceptions have no stack traces, which makes them.. much less useful.
Attached patch (0001-hack-ex-info-stacktraces.patch) is one hackish way of getting stack traces back when Error.captureStackTrace is available (at least in Chrome, presumably in Node as well).
But this seems unacceptable — all the stuff emitted for the deftype (making the constructor print as a type) gets overwritten.
Is there a better way?
Will this maybe be made irrelevant by source maps?
|Comment by David Nolen [ 23/Dec/12 11:51 AM ]|
Isn't the stack trace recoverable from the original exception?
|Comment by Tom Jack [ 23/Dec/12 4:01 PM ]|
I hadn't considered that. If a cause is provided, that seems reasonable. The only trouble is that you still have to know where the ExceptionInfo is being thrown, so that you can catch it and throw the cause. Chrome's debugger would make it easy to at least find where the ExceptionInfo is thrown, but it's still more trouble than having the appropriate stack trace directly on the ExceptionInfo.
If no cause is provided, of course that won't work. But I suppose one could write (ex-info msg data (js/Error.)) instead of (ex-info msg data)? Personally, I don't expect to pass a cause very often — I expect the binary arity to be much more common in my cljs libraries.
If we rely on the cause for the stack trace, maybe we could have the cause default to a new Error if not supplied? It seems sort of conceivable that we could also wire up the ExceptionInfo to proxy .stack to that Error so that the stacktrace will come through, without needing to override the ExceptionInfo constructor.
|Comment by David Nolen [ 03/Jan/15 6:12 PM ]|
Sorry for letting this one languish, it appears stack traces just work under Node.js. However that doesn't seem to be the case in browsers. I would take a rebased patch, thanks.
|Comment by David Nolen [ 21/Feb/15 7:11 AM ]|