4 ms·

> Proponents of exceptions may say, “this is so much manual writing labor, exception stack trace would automate that!” Yes indeed. > by writing custom message

> Proponents of exceptions may say, “this is so much manual writing labor, exception stack trace would automate that!” Yes indeed. > by writing custom messages, we can provide more details useful for debugging (for example, the os.ReadFile helped us with a filename); Custom exceptions anyone ? > by not relying on code line numbers, the messages are more long-lived, and can actually be understood and reasoned about in isolation, without access to the source code. Doubt... I quite like Go (some aspects of it anyway) and it's proven both useful and successful, but some people will go great length to find virtues in its weaknesses.

the_gipsy 2y ago
You don't need the horrible mess of exceptions to get stacktraces on errors. You can tack on stacktraces on go's errors manually, but it's somewhat limited. Rust has some env var to enable stacktraces IIRC, which is a better solution.
throwaway2037 2y ago
This is a great post. I also respect Go. However, I don't understand the allergy to exceptions. Even the part about them adding extra debug details to the message. Hmm, looks just like a chained exception from Java/Python. Oh wait, without the helpful exception stack trace. It reminds me of the multi-year arguments about generics in Go. Obviously, they were needed, yet 100s(?) of blog posts were written about why we didn't need them. They have aged like fresh milk -- not well. See the same discussion about the keyword "final" in C++ to seal a class. For years, C++ was allergic to ideas from any other language that came after. Things are different now.
- mst 2y ago
  I think the reality re generics was that the authors of Go wanted to see what people did instead to understand the patterns of usage so when they -did- add generics they could provide the simplest thing required. Which is probably the only real way to figure out what 'simplest' is, I deliberately spent a couple of years writing OO perl code raw (i.e. the low level bless() based stuff that you normally only use for optimisations) to figure out which features of p3rl.org/Moose I couldn't live without - and came out the other side with a solid spec for p3rl.org/Moo which has since proven pretty much spot on as "what almost everybody needs almost all of the time." Using their entire userbase as guinea pigs rather than only themselves is only going to work better for that. (I'm not necessarily endorsing the choices, but I can see why they were made and why they were effective)
- 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 ago
    This 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)

the_gipsy 2y ago

You don't need the horrible mess of exceptions to get stacktraces on errors. You can tack on stacktraces on go's errors manually, but it's somewhat limited. Rust has some env var to enable stacktraces IIRC, which is a better solution.

throwaway2037 2y ago

This is a great post. I also respect Go. However, I don't understand the allergy to exceptions. Even the part about them adding extra debug details to the message. Hmm, looks just like a chained exception from Java/Python. Oh wait, without the helpful exception stack trace. It reminds me of the multi-year arguments about generics in Go. Obviously, they were needed, yet 100s(?) of blog posts were written about why we didn't need them. They have aged like fresh milk -- not well. See the same discussion about the keyword "final" in C++ to seal a class. For years, C++ was allergic to ideas from any other language that came after. Things are different now.

mst 2y ago
I think the reality re generics was that the authors of Go wanted to see what people did instead to understand the patterns of usage so when they -did- add generics they could provide the simplest thing required. Which is probably the only real way to figure out what 'simplest' is, I deliberately spent a couple of years writing OO perl code raw (i.e. the low level bless() based stuff that you normally only use for optimisations) to figure out which features of p3rl.org/Moose I couldn't live without - and came out the other side with a solid spec for p3rl.org/Moo which has since proven pretty much spot on as "what almost everybody needs almost all of the time." Using their entire userbase as guinea pigs rather than only themselves is only going to work better for that. (I'm not necessarily endorsing the choices, but I can see why they were made and why they were effective)
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 ago
  This 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)