3 ms·
I think the main problem with stack traces is that they incur huge performance hit whenever they are created. Wrapping errors with each error having their own s
by DanielHB 2y ago
I think the main problem with stack traces is that they incur huge performance hit whenever they are created. Wrapping errors with each error having their own stack trace can create huge performance problems if they happen as normal course of the application.
Panics in go do have traces, in practice they work like RuntimeExceptions in Java.
Overall I think Go makes a good compromise in this aspect, but it requires the developer to know how to structure their error handling in a way that it is easy to debug when the errors do happen (which is also true, and potentially harder, with exceptions).
- mst 2y agoThis is why I tend to think 'catch' blocks would ideally run in the dynamic scope of the 'throw' such that you can decide whether or not to gather a stack trace at the point of catch rather than the point of throw. Common Lisp conditions are the only thing I've used that provides that. (well, perl's $SIG{__DIE__} + local to dynamically scope the override will somewhat let you do that, but it's a bit deep magic and something developers normally only ever interact with through a library rather than a basic feature)