Hacker News Reader

Comment by seabrookmx | Hacker News Reader

> Avoiding exceptions is a worst practice

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.

View on HN

> The Linux kernel is an impressively complicated, and robust piece of software and they get along just fine without exceptions.

The amount of error-unwinding goto spaghetti, ERR_CAST/IS_ERR/PTR_ERR/... and all the bugs coming from it is not "just fine".

But how much of that would be solved by exceptions without convertng to a fully garbage-collected language?

Dunno.

Passing -ENOMEM 5 layers upwards stops being fun very quickly.

In fact at the kernel level there are plenty of mechanisms that are comparable to exceptions, e.g. longjmps, software interruptions, signals ...

Edit: clarity.

Cindy Rubio-Gonzalez has some fascinating empirical analyses of error handling in the Linux kernel: http://www.eecs.berkeley.edu/~rubio/

The tl;dr is that errors get dropped a lot with return codes. It's so easy to do, even in battle-tested, critical code like the Linux kernel.

I found this one compelling:

http://nedbatchelder.com/text/exceptions-in-the-rainforest.h...

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.

Reply on news.ycombinator.com