3 ms·
Errors are different in every stdlib or 3rd party package I've ever used. The ecosystem as a whole decided that errors should be useful, values, and properly b
by Xeoncross 3y ago
Errors are different in every stdlib or 3rd party package I've ever used.
The ecosystem as a whole decided that errors should be useful, values, and properly bubbled up - and that your application should not be so hard to reason about that you need a stack trace to know where in the deep recesses of your code something went wrong.
I love stack traces in Java, but I don't miss them at all in Go.
- the_gipsy 3y agoSounds a bit apologetic. I don't think that the ecosystem decided. The language creators decided, and the ecosystem couldn't do much about it.
- Cthulhu_ 3y agoGo's development process is fairly open and democratic though; if enough people flag it up, and if a case can be made for stack traces, it can be added. As it stands though, the consensus is that it doesn't add enough value, it's too expensive (cost/benefit), errors are normal program flow, and 3rd party libraries can add the functionality if one decides they need/want it in their application.
- Xeoncross 3y agoI say ecosystem to mean the majority of packages. That's the ecosystem.
- eweise 3y ago"your application should not be so hard to reason about that you need a stack trace to know where in the deep recesses of your code something went wrong." Curious how Go is better than other languages in this regard.
- Cthulhu_ 3y agoThat quote isn't about Go specifically though, but about general application design. It seems to be a subtle snipe that languages with stacktraces like Java, C# are too complicated or have too many layers ("lasagna code"), making them more difficult to debug.