[pingyong]

When your main argument for not using exceptions for every kind of error handling is performance instead of architecture, then maybe it is a sign that exceptions should simply be constructed to be more performant instead of giving people advice that isn't and can't ever be consistent.

As the writer of a library (or just other utility functions), you simply cannot know whether something is an exceptional situation or not, because that is a property of the program and the environment, not the function. Being unable to parse a string to a number, or to create a socket, or to even allocate memory can all be exceptional or not exceptional depending on the context, and often you simply do not know the context this code will run in, or the code will actually run in multiple directly contradictory contexts.

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

[mratsim]

I totally agree for things like streams or IO like file handling or authentication. It may be fatal at the IO layer but in a GUI you want a nice error displayed to the user and not a crash.

However in some domains you don't want to pollute your return value with a Result or Error enum, for example a BigInt library addition or a Matrix addition would be much more convenient for scientists to use if it returned a BigInt or Matrix respectively.

[UK-Al05]

With bind style semantics its not that bad using result types for matrix or bigint.

[ailideex]

> When your main argument for not using exceptions for every kind of error handling is performance instead of architecture

Personally I find that using exceptions quite broadly makes it easier to build fault tolerant software. And to me this makes the performance issue rather moot. Some classes, such as, financial OLTP systems, should much rather be correct and resilient than performant.

I could presumably write the same exact logic in asynchronous C, but most likely it will have serious stability issues. And what is more, every person I have come across in my life that insisted on writing asynchronous code for financial OLTP systems ended up writing software which would never have the requisite stability and had to either be abandoned or rewritten.

To me, avoiding exceptions absolutely seems like trying to fix a problem that is not related to how code is written by changing how code is written - instead of changing how the code is executed, which is where the actual problem comes in.

Another argument I hear all too frequently though is that people can just ignore exceptions ... and yes - they can - and in almost all cases (unless someone did not just ignore exceptions) this will cause program or thread termination.

In C you can just ignore error return values also - but what is worse - you can forget to check them - and then execution continues as if everything is fine. With exceptions you guarantee that someone has to go out of their way to continue execution as if everything is fine if something went wrong.

This is why exceptions are optimal for happy path programming.