If you're in the

If you're in the "we don't use exceptions" camp, then how do you use the standard library?

Note: I'm not playing the devil's advocate or anything like that here - I'm just genuinely curious since I'm not in this camp myself.

Most types in the standard library have either mutating functions that can throw exceptions (for instance if memory allocation fails) or non-mutating functions that can throw exceptions (for instance out of bounds indexed accessors). In addition to that, many free functions can throw exceptions (for instance operator new and dynamic_cast).

How do you practically deal with this in the context of "we don't use exceptions"?

• Are you trying to never call a function that can throw? (I can't see how that'd scale, so I'm very interested to hear how you accomplish this if this is the case)

• Are you ok with the standard library throwing and you treat "we don't use exceptions" as "we never throw exceptions from our code and we never catch exceptions from other's code"?

• Are you disabling exception handling altogether via compiler switches? If so, how do the exception-throwing parts of the standard library work?

• EDIT Your constructors, can they fail, or do you by convention use a 2-step construction with a dedicated init function that can return an error code upon failure (which the constructor can't), or do you do something else?

EDIT Minor clarification 1 week after the inception of the question... Much of the content in comments and questions below focus on the why aspects of exceptions vs "something else". My interest is not in that, but when you choose to do "something else", how do you deal with the standard library parts that do throw exceptions?

Answer by Niall for If you're in the "we don't use exceptions" camp, then how do you use the standard library?

Note I use exceptions... but I have been forced not to.

Are you trying to never call a function that can throw? (I can't see how that'd scale, so I'm very interested to hear how you accomplish this if this is the case)

This would probably be infeasible, at least on a large scale. Many functions can land up throwing, avoid them entirely cripples your code base.

Are you ok with the standard library throwing and you treat "we don't use exceptions" as "we never throw exceptions from our code and we never catch exceptions from other's code"?

You pretty much have to be ok with that... If the library code is going to throw an exception and your code is not going to handle it, termination is the default behaviour.

Are you disabling exception handling altogether via compiler switches? If so, how does the exception-throwing parts of the standard library work?

This is possible (back in the day it was sometime popular for some project types); compilers do/may support this, but you will need to consult their documentation for what the result(s) would and could be (and what language features are supported under those conditions).

In general, when an exception would be thrown, the program would need to abort or otherwise exit. Some coding standards still require this, the JSF coding standard comes to mind (IIRC).

General strategy for those who "don't use exceptions"

Most functions have a set of preconditions that can be checked for before the call is made. Check for those. If they are not met, then don't make the call; fall back to whatever the error handling is in that code. For those functions that you can't check to ensure the preconditions are met... not much, the program will likely abort.

You could look to avoid libraries that throw exceptions - you asked this in the context of the standard library, so this doesn't quite fit the bill, but it remains an option.

Other possible strategies; I know this sounds trite, but pick a language that doesn't use them. C could do nicely...

...crux of my question (your interaction with the standard library, if any), I'm quite interested in hearing about your constructors. Can they fail, or do you by convention use a 2-step construction with a dedicated init function that can return an error code upon failure (which the constructor can't)? Or what's your strategy there?

If constructors are used, there are generally two approaches that are used to indicate the failure;

1. Set an internal error code or enum to indicate the failure and what the failure is. This can be interrogated after the object's construction and appropriate action taken.
2. Don't use a constructor (or at least only construct what cannot fail in the constructor - if anything) and then use an init() method of some sort to do (or complete) the construction. The member method can then return an error if there is some failure.

The use of the init() technique is generally favored as it can be chained and scales better than the internal "error" code.

Again, these are techniques that come from environments where exceptions do not exist (such as C). Using a language such as C++ without exceptions limits its usability and the usefulness of the breadth of the standard library.

Answer by Zouch for If you're in the "we don't use exceptions" camp, then how do you use the standard library?

In our case, we disable the exceptions via the compiler (e.g -fno-exceptions for gcc).

In the case of gcc, they use a macro called _GLIBCXX_THROW_OR_ABORT which is defined as

#ifndef _GLIBCXX_THROW_OR_ABORT  # if __cpp_exceptions  #  define _GLIBCXX_THROW_OR_ABORT(_EXC) (throw (_EXC))  # else  #  define _GLIBCXX_THROW_OR_ABORT(_EXC) (__builtin_abort())  # endif