| |||||||||||||
Exception tracesException tracesPosted Jul 4, 2012 13:09 UTC (Wed) by man_ls (subscriber, #15091)In reply to: Quotes of the week by twm Parent article: Quotes of the week With exceptions users have a nice stack trace that they can send to the developer. At the uppermost level I just catch the errors to print them nicely along with debug information. When people send me stack traces I can find the error almost instantly. In the Google Play App Store (or however it is called this week) they have taken this idea to the next level: when the user clicks on "inform the developer" Google aggregates the information and shows the traces to the developer. Try doing that with ignored error values...
(Log in to post comments)
Exception traces Posted Jul 6, 2012 4:15 UTC (Fri) by twm (guest, #67436) [Link] The concept of a stack trace is not part of the exception error handling model. You can get stack traces in Go too; runtime.Callers looks like a good place to start.
Exception traces Posted Jul 6, 2012 8:05 UTC (Fri) by man_ls (subscriber, #15091) [Link] Well, then I suppose you need both exceptions and stack traces. The idea being that the stack trace is generated automatically by the runtime environment at the point that throws the exception and handled in the catch clause. Without exceptions stack traces have to be generated manually, which is not useful for unexpected error conditions.
Exception traces Posted Jul 11, 2012 6:51 UTC (Wed) by jamesh (guest, #1159) [Link]
Does that help you at the top level if you've called some well behaved Go code that checks and passes up error conditions, and you want to know precisely where the error originated?
Wouldn't an exception + stack trace be easier to debug?
|
|||||||||||||