Closed
Bug 757892
Opened 12 years ago
Closed 7 years ago
console.trace could take an exception argument
Categories
(DevTools :: Console, defect, P3)
Tracking
(Not tracked)
RESOLVED
WONTFIX
People
(Reporter: ianbicking, Unassigned)
Details
It would be nice if you could get a trace not just of a particular place in code, but of an exception. I'd propose that console.trace(exception) do just that. E.g.: try { runMyCode(); } catch (e) { console.trace(e); }
Comment 1•12 years ago
|
||
This is a nice suggestion, but I think we should at least coordinate with Firebug and probably other browsers, as the console API is a de facto standard, now. I wish the W3C WG (http://www.w3.org/2011/08/browser-testing-charter.html) was active on the console API.
Comment 2•12 years ago
|
||
Adding Honza. 'console.error(ex.stack);' works both in the web console and in firebug, but iirc, it's broken in many other places, and it's ugly. function broken() { null.dereference; } try { broken(); } catch (ex) { console.error('it broke here', ex.stack); } Chrome has a nice formatter for exceptions, so you can do console.error(ex);
Reporter | ||
Comment 3•12 years ago
|
||
console.error seems just as good, and I suppose would only require a better inspector for exception objects.
Comment 4•12 years ago
|
||
So, if I understand correctly this report, instead of printing JS stack trace at the point where it is called, console.trace() would print stack trace of the passed error object, right? (which how console.error works now) Honza
Comment 5•12 years ago
|
||
(In reply to Jan Honza Odvarko from comment #4) > So, if I understand correctly this report, instead of printing JS stack > trace at the point where it is called, console.trace() would print stack > trace of the passed error object, right? (which how console.error works now) I don't think Ian cares about the method name, he just wants a way to show the stack from a caught exception without tricks (i.e. ex.stack)
Reporter | ||
Comment 6•12 years ago
|
||
ex.stack is also not as pleasant as what console.trace() displays, and console.error(ex) isn't very nice at all. Joe's example in Comment 2 displays "(new TypeError("null has no properties", "Web Console", 3)) @ Web Console:9"
Comment 7•12 years ago
|
||
So, I like the suggestion of passing the exception/error object into console.trace() - in which case it would print stack trace of the passed object. Honza
Comment 8•12 years ago
|
||
(In reply to Jan Honza Odvarko from comment #7) > So, I like the suggestion of passing the exception/error object into > console.trace() - in which case it would print stack trace of the passed > object. Is there a reason not to use an exception formatter for console.error(ex);
Comment 9•12 years ago
|
||
(In reply to Joe Walker from comment #8) > (In reply to Jan Honza Odvarko from comment #7) > Is there a reason not to use an exception formatter for console.error(ex); Good question, I don't know. The reason I like the original suggestion is that console.trace would be more flexible... Honza
Comment 10•12 years ago
|
||
(In reply to Jan Honza Odvarko from comment #9) > (In reply to Joe Walker from comment #8) > > (In reply to Jan Honza Odvarko from comment #7) > > Is there a reason not to use an exception formatter for console.error(ex); > Good question, I don't know. > > The reason I like the original suggestion is that console.trace would be > more flexible... In what way could it be more flexible?
Comment 11•12 years ago
|
||
(In reply to Joe Walker from comment #10) > (In reply to Jan Honza Odvarko from comment #9) > > (In reply to Joe Walker from comment #8) > > > (In reply to Jan Honza Odvarko from comment #7) > > > Is there a reason not to use an exception formatter for console.error(ex); > > Good question, I don't know. > > > > The reason I like the original suggestion is that console.trace would be > > more flexible... > > In what way could it be more flexible? So that I can pass an error/exception object (or an object with 'stack' field) into it and see its stack trace. Currently it can only print stack trace of the location where it's executed. (note that the purpose of console.trace is to print interactive stack traces) Honza
Comment 12•12 years ago
|
||
Do we think changing the semantics of console.trace is a good idea? I suppose we'd be adding functionality by implementing the suggestions here (optional Exception argument). The alternative, beefing up console.error to produce nice stacktraces seems like a reasonable solution as well. console.error has been somewhat under-defined, making it produce similar output to trace's from exceptions could be alright. If I'm not coming down strongly for either side, it's because I think they're both fine suggestions. I don't think either implementation would break existing debug code, though feel free to correct me if I'm making a bad assumption. :)
Reporter | ||
Comment 13•12 years ago
|
||
It might be difficult to reliably show much with an exception object anyway, for example: try {throw 'hey'} catch (e) {console.log(e, e.stack, typeof e)} > hey undefined string There's nothing much to inspect there. If you could get something to inspect via some secret mechanism that would be great! But assuming there is no backdoor (e.g., if the stack from the previous exception was stored somewhere) then there's a limit to how much can be done.
Comment 14•12 years ago
|
||
(In reply to Rob Campbell [:rc] (:robcee) from comment #12) > The alternative, beefing up console.error to produce nice stacktraces seems > like a reasonable solution as well. console.error has been somewhat > under-defined One nice improvement for console.error() could be displaying two stack-traces for exceptions. 1) One for the location where the exception has been thrown. 2) One for the location where the console.error is executed. Not sure how the UI would look like, but I would often like to see both. Honza
Updated•11 years ago
|
Priority: -- → P3
Comment 15•7 years ago
|
||
Inactive for the past 5 years. Closing now.
Status: NEW → RESOLVED
Closed: 7 years ago
Resolution: --- → WONTFIX
Updated•6 years ago
|
Product: Firefox → DevTools
You need to log in
before you can comment on or make changes to this bug.
Description
•