5 ms·

Avoiding exceptions is a worst practice. The guide even admits they're only doing it because they're so far beyond a critical mass of exception-unsafe code that

Avoiding exceptions is a worst practice. The guide even admits they're only doing it because they're so far beyond a critical mass of exception-unsafe code that they've lost hope of solving the problem. If the profession ever wants to produce anything reliable in C++, one of the first things that needs to happen is to start treating all unsafe legacy code like toxic waste, marking it clearly, handling it carefully in isolation, and disposing of it with prejudice as soon as possible. I don't ever expect to see this, which is partly why I switched to languages that try to handle failures and mistakes gracefully.

nly 13y ago
Avoiding exceptions isn't the worst practice. You still get automatic resource cleanup with RAII when you return from a function with an error code, which is a big win over completely unmanaged C. I generally agree though, error paths are the last area I want to expose myself to flaky manual propagation and the 'well, I think I handled/freed everything' discipline. The regimental 'goto cleanup' type code you see in the kernel is not something I want in my projects.
seabrookmx 13y ago
> 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 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.
- mixmastamyk 13y ago
  I found this one compelling: http://nedbatchelder.com/text/exceptions-in-the-rainforest.html http://nedbatchelder.com/text/exceptions-in-the-rainforest.h...
  - seabrookmx 13y ago
    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.
- bnegreve 13y ago
  In fact at the kernel level there are plenty of mechanisms that are comparable to exceptions, e.g. longjmps, software interruptions, signals ... Edit: clarity.
- adobriyan 13y ago
  > 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".
  - throwawaykf03 13y ago
    But how much of that would be solved by exceptions without convertng to a fully garbage-collected language?
    - adobriyan 13y ago
      Dunno. Passing -ENOMEM 5 layers upwards stops being fun very quickly.
- stinos 13y ago
  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 https://en.wikipedia.org/wiki/List_of_fallacies and figure out which one you just used :P
- prodigal_erik 13y ago
  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.
  - seabrookmx 13y ago
    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.
- pcwalton 13y ago
  Cindy Rubio-Gonzalez has some fascinating empirical analyses of error handling in the Linux kernel: http://www.eecs.berkeley.edu/~rubio/ 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.
thepicard 13y ago
>If the profession ever wants to produce anything reliable in C++ This has already been done, so you are obviously wrong. Exceptions are cute for small amounts of code. But as soon as you get a sizeable codebase, you have zillions of functions just waiting to explode your call stack in ways you could never expect. Documentation doesn't fix it either. Even if you could somehow guarantee that every single function has detailed descriptions of its possible throws, you won't get devs to read all the documentation for every function in some piece of code that needs a small fix.
- TheMiller 13y ago
  > Exceptions are cute for small amounts of code. But as soon as you get a sizeable codebase, you have zillions of functions just waiting to explode your call stack in ways you could never expect. Exceptions do not "explode your call stack", and any function can fail in ways both documented and undocumented. Consistent use of exceptions that derive from a small and well-chosen set of base classes means that callers can choose where and how to respond to categories of errors, instead of being forced to litter all code with error handling conditionals. I have worked on large applications that made the transition to using exceptions, and when combined with strict RAII and other best practices, the effect is absolutely to make code easier to understand and much more robust.
  - iribe 13y ago
    The key is "small and well chosen set of base classes" for your exceptions. This is where you got the most benefit, and you probably know it. Without exceptions, you can have a class that represents well defined state such as either success or an error code, with the error code being well defined, returning an object of this class for all methods that need to return success/failure codes, and requiring that it be handled, so compilation fails if callers ignore the return value. What's great about this is I might call a method that simply concatenates two strings, that is all it does, and I know this won't fail(OOM can always happen, but good luck recovering from that), so I don't return a status. I can call this method assuming no failure and no boiler plate is needed. With exceptions, there's always that possibility that an exception can be thrown. What if I call this method from code that needs to close resources? Great, now I absolutely must have RAII for cleanup, which is more complicated than just doing close(x). Also, what are you going to do when using 3rd party code with its own base exception class? Now, at the upper layers of your code, you have to have a handler for each base class. Without exceptions, someone might have their own status object they return, and I'll need to translate that, else my code won't compile. Your code will compile even though you might not handle that 3 party base exception class. Of course, most times code just propagates the error up so that adds to boiler plate without exceptions. I think the talk of using exceptions vs returning a status is a red herring. They have their positives and negatives, and we can argue this until the cows come home. The most important thing is to use a set of well defined success/error codes, whether this comes from exceptions or a returned status isn't really important. I've seen codebase with C++ exceptions working just fine, and I've seen c++ code with no exceptions, and it worked well. The commonality between these two cases is .... well defined error codes.
flohofwoe 13y ago
I remember that last-gen game console SDK's explicitly recommended to avoid exceptions and disable them completely for performance reasons, and all C++ game-dev middleware I'm aware of don't use them or at least have support for disabling them. Don't know what the recommendation in the current console SDK's is. I never got into a situation where I thought "gosh, exceptions would be really nice to have in here".

nly 13y ago

Avoiding exceptions isn't the worst practice. You still get automatic resource cleanup with RAII when you return from a function with an error code, which is a big win over completely unmanaged C. I generally agree though, error paths are the last area I want to expose myself to flaky manual propagation and the 'well, I think I handled/freed everything' discipline. The regimental 'goto cleanup' type code you see in the kernel is not something I want in my projects.

seabrookmx 13y ago

> 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 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.

mixmastamyk 13y ago
I found this one compelling: http://nedbatchelder.com/text/exceptions-in-the-rainforest.html http://nedbatchelder.com/text/exceptions-in-the-rainforest.h...
- seabrookmx 13y ago
  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.
bnegreve 13y ago
In fact at the kernel level there are plenty of mechanisms that are comparable to exceptions, e.g. longjmps, software interruptions, signals ... Edit: clarity.
adobriyan 13y ago
> 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".
- throwawaykf03 13y ago
  But how much of that would be solved by exceptions without convertng to a fully garbage-collected language?
  - adobriyan 13y ago
    Dunno. Passing -ENOMEM 5 layers upwards stops being fun very quickly.
stinos 13y ago
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 https://en.wikipedia.org/wiki/List_of_fallacies and figure out which one you just used :P
prodigal_erik 13y ago
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.
- seabrookmx 13y ago
  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.
pcwalton 13y ago
Cindy Rubio-Gonzalez has some fascinating empirical analyses of error handling in the Linux kernel: http://www.eecs.berkeley.edu/~rubio/ 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.

thepicard 13y ago

>If the profession ever wants to produce anything reliable in C++ This has already been done, so you are obviously wrong. Exceptions are cute for small amounts of code. But as soon as you get a sizeable codebase, you have zillions of functions just waiting to explode your call stack in ways you could never expect. Documentation doesn't fix it either. Even if you could somehow guarantee that every single function has detailed descriptions of its possible throws, you won't get devs to read all the documentation for every function in some piece of code that needs a small fix.

TheMiller 13y ago
> Exceptions are cute for small amounts of code. But as soon as you get a sizeable codebase, you have zillions of functions just waiting to explode your call stack in ways you could never expect. Exceptions do not "explode your call stack", and any function can fail in ways both documented and undocumented. Consistent use of exceptions that derive from a small and well-chosen set of base classes means that callers can choose where and how to respond to categories of errors, instead of being forced to litter all code with error handling conditionals. I have worked on large applications that made the transition to using exceptions, and when combined with strict RAII and other best practices, the effect is absolutely to make code easier to understand and much more robust.
- iribe 13y ago
  The key is "small and well chosen set of base classes" for your exceptions. This is where you got the most benefit, and you probably know it. Without exceptions, you can have a class that represents well defined state such as either success or an error code, with the error code being well defined, returning an object of this class for all methods that need to return success/failure codes, and requiring that it be handled, so compilation fails if callers ignore the return value. What's great about this is I might call a method that simply concatenates two strings, that is all it does, and I know this won't fail(OOM can always happen, but good luck recovering from that), so I don't return a status. I can call this method assuming no failure and no boiler plate is needed. With exceptions, there's always that possibility that an exception can be thrown. What if I call this method from code that needs to close resources? Great, now I absolutely must have RAII for cleanup, which is more complicated than just doing close(x). Also, what are you going to do when using 3rd party code with its own base exception class? Now, at the upper layers of your code, you have to have a handler for each base class. Without exceptions, someone might have their own status object they return, and I'll need to translate that, else my code won't compile. Your code will compile even though you might not handle that 3 party base exception class. Of course, most times code just propagates the error up so that adds to boiler plate without exceptions. I think the talk of using exceptions vs returning a status is a red herring. They have their positives and negatives, and we can argue this until the cows come home. The most important thing is to use a set of well defined success/error codes, whether this comes from exceptions or a returned status isn't really important. I've seen codebase with C++ exceptions working just fine, and I've seen c++ code with no exceptions, and it worked well. The commonality between these two cases is .... well defined error codes.

flohofwoe 13y ago

I remember that last-gen game console SDK's explicitly recommended to avoid exceptions and disable them completely for performance reasons, and all C++ game-dev middleware I'm aware of don't use them or at least have support for disabling them. Don't know what the recommendation in the current console SDK's is. I never got into a situation where I thought "gosh, exceptions would be really nice to have in here".