A good error message might look like this:
Could not travel to Alpha Centauri:
warp drive initialization failed:
power coupling 397 is offline:
temperature out of range (temp = 150°C)
DeviceClient::Connect()
std::promise::something
<anonymous function>
DeviceSet::PowerOnAllDevices()
<anonymous function>
std::etcetera
std::etcetera<some_big_thing, more_params, allocator=std::allocator>
TravelCommand::Engage()
VoiceCommand::RunCommand()
Error: temperature out of range (temp = 150°C)
Exceptions optimize for the case where the exception bubbles straight up to some handler, but I'd rather not have my errors work that way. It's incredibly common for it to make no sense to bubble an error up without some kind of annotation or additional context.
return errors.New("")
Stack traces are not like this, you can't really control whether they are good or bad, at least not well. If you want to make your stack traces more informative what do you do? You can't really change them, they just reflect your call graph.
Golang optimizes for the case where you get good error messages. Exceptions optimize for the case where you don't care about adding context to the error and just want to bubble it upwards. On the balance of things, I prefer Golang's approach because most of the time, I don't want to see the stack trace.
[Edit: this was a reply to a comment you seem to have rewritten (I think for the worse) but I think the response still mostly works]
errors are "failure as data" (hence, message), and you get to write the flow (including handling and annotating the call stack)
vs
exceptions are "failure as flow" (hence, stack trace), and you get to write the data (including logging)
May very well be paraphrasing a well known maxim about closures and objects as errors are a poor man's exceptions and exceptions are a poor man's errors.
try {
MyType x{args, args};
x.DoSomething();
} catch (SomeException &e) {
...
}
If you're mentally comparing against the way error handling in C, your position is much more defensible. Error handling in C requires manually releasing resources in the correct order, and it's easy for a destructor to slip by in the wrong order, to get missed entirely, or for someone to use the wrong jump label. (I'm thinking about Linux kernel style code, here.) If I'm reviewing some error handling code in C, I might have to scan up to the top of the function and count all the resources which need to be released, then look down to the bottom to see that the right label is being jumped to. That's a pain.
In languages like Golang, error handling and resource cleanup are a bit more orthogonal. You can look at a Golang call which returns an error and ask, "Does this handle the error correctly?" Usually this only requires looking at three lines of code at a time, maybe four. Resources are just released with defer, except in unusual cases.
> Once you get in the habit, it's not hard to scan through a program line-by-line asking yourself "what would happen if an exception were thrown at this point?"
I guess I never got in the habit. Maybe you have better habits than I do, or maybe I'm just not "smart enough" to be a programmer, but I find this hard, so I choose to use languages which make this easier. I find it hard in Python, hard in JavaScript, hard in C++, and hard in C#. I'm really not even sure how to e.g. handle exceptions thrown by C++ constructor failures separately from other things later in the block, e.g., I want to do this:
And I'm not sure how to even write this as functional C++ without doing something weird or maybe just saying "fuck it" and wrapping x in std::unique_ptr.> In fact, I'd wager that for anyone who's spent years working in any language with exceptions this quickly becomes second nature.
Based on what I see during code reviews, I don't agree. Raymond Chen has a good point... when I review someone's Golang code, checking for correct error handling is fast and easy, it's mostly mechanical, easy to target with lint, and I can immediately move on to looking at the code semantics. With, say, C# code, or especially Python code, there are too many cases where a method call slips inside or outside the try/catch block where it belongs.
I've also been bitten too many times by bugs in production where a function throws an exception, and we have to decode the stack trace to figure out what the error means or how the error is even possible. This is typically easier in programs written in Golang, at least in my experience.
The more syntactic sugar a language has, the more likely it is that I don't notice an error condition that is being handled incorrectly. Golang, with its simplicity, makes you do some extra typing up front but in my experience it pays for itself by going faster through code review and bug fixes.
This depends on the kind of code you're writing. If you're mostly sticking inside application memory and not doing, e.g., IO, IPC, etc, then the exception approach is better.
I'm not saying Golang is perfect by any means, but I find the way it does error handling to be a welcome reduction in my cognitive load.