You say this very matter-of-factly. Many (myself included) do not believe in exceptions, and in C++ where they are poorly implemented, think not using them is best practice.
I would summarize, but this 10 year old article I've seen on HN a dozen times does a much better job than I:
Error handling is essential, but exceptions are far from a perfect solution. The Linux kernel is an impressively complicated, and robust piece of software and they get along just fine without exceptions. One just needs to be vigilant when handling errors.
I didn't really. IMHO as many in the comments stated, non-trivial "B" layer code makes the author's approach a mess.
Also I don't personally agree with the idea that exceptions communicate errors better. In his examples, he's taking an error code and converting it to an exception. Obviously all the information needed about that error is conveyed by the code, otherwise this approach wouldn't work.
Wrangling of this information shouldn't be happening in the middle of application logic. The return code should be acknowledged by the recipient so the necessary cleanup can be performed, then it should be piped to a central class in charge of printing/logging errors. Sprinkling these error code conversions all over the place makes things messy and hard to maintain.
The Linux kernel is an impressively complicated, and robust piece of software and they get along just fine without exceptions
Though I somewhat agree with you, in that C++ exceptions definitely are not the error handling method, such examples don't really mean nor prove much for this subject. Especially since the kernel isn't even written in C++ and is a pretty special beast compared to, say, a typical desktop or app. So now browse to https://en.wikipedia.org/wiki/List_of_fallacies and figure out which one you just used :P
I would never describe Linux as "robust". It seems everyone I know has seen it panic more than once, and shrugged it off not by fixing anything but by power-cycling the machine and hoping it doesn't happen too often. This means on top of a database of tens of thousands of bugs, there have been countless catastrophic failures which have never even been diagnosed. We only use it because everything else is at least that embarrassingly terrible and probably even worse.
Taking software seriously involves ensuring every failure is handled. Dropping them on the floor is almost never the right thing, which makes it crazy to have that quietly happen by default. Joel points out code without exceptions becomes very verbose and littered with local handling, but overlooks that it's so painful that most developers can't be relied on to actually do it.
I run quite a few linux boxes, and make them do lots of real work. Compared to other pieces of software, I find it quite reliable. This is especially true if you take into consideration the breadth of tasks and the performance requirements needed out of a monolithic kernel.
I'm in no way saying its perfect though.
> Taking software seriously involves ensuring every failure is handled
> it's so painful that most developers can't be relied on to actually do it
I agree with both of those points (as any decent developer would), but I don't believe exceptions remedy either of those issues.
The architects behind Go, truely some of the best minds in computer science, did not include exceptions because of this.
You say this very matter-of-factly. Many (myself included) do not believe in exceptions, and in C++ where they are poorly implemented, think not using them is best practice.
I would summarize, but this 10 year old article I've seen on HN a dozen times does a much better job than I:
http://www.joelonsoftware.com/items/2003/10/13.html
Error handling is essential, but exceptions are far from a perfect solution. The Linux kernel is an impressively complicated, and robust piece of software and they get along just fine without exceptions. One just needs to be vigilant when handling errors.