[dgellow]

As a library writer you can let the caller the responsibility to determine if something is worth throwing an exception for or not.

1. return an error code

2. if the caller consider the issue to require an exception, they will do it themselves

You can also have entrypoints to the library that will throw exceptions, and other versions that won't, and let the caller decide what they want to use.

Though of course that's more work.

Regarding the point of performances, that makes me think of https://news.ycombinator.com/item?id=22483028, discussing "Low-cost Deterministic C++ Exceptions for Embedded Systems". It would definitely be very interesting to see what is now possible if exceptions are cheaper.

[pingyong]

The problem with doing that as a library writer is that exceptions, used well, generally change the entire interface and to some extent programming model. It starts with simple things like returning values instead of an error code (and setting value by reference) and goes through having to make "factory" functions for classes (if you want to use error codes) and ends with all sorts of considerations like copy constructors in C++.

So in many cases, if you don't want to compromise on design and architecture, you essentially need to write the entire library twice, or at least the entire interface. Not really a great state.

>discussing "Low-cost Deterministic C++ Exceptions for Embedded Systems"

This exact reason is why I think that paper is great and also how exceptions should have been implemented in C++ in the first place.