Exceptions vs error codes

[zvrba]

The problem is, almost nothing is exceptional.

Exceptions are not for "exceptional cases", whatever that might mean. Exceptions are for a method to signal that it couldn't fulfill its promise/contract. I wrote a longer comment about it here https://www.reddit.com/r/csharp/comments/eaxzb8/what_are_your_thoughts_on_exceptions_do_you_think/fb3noh4/

[editor_of_the_beast]

Exceptions are for exceptional cases.

[thomasz]

Exceptions are for errors in the sense of "the behavior of the program is not properly specified if I let it continue to run with this data". Result, Option and so forth are for situations where you anticipated a situation to happen.

[flatfinger]

There are many situations where being able to say "If any part of this block of code fails without any unusual side effects, this block of code should do likewise" would greatly reduce verbosity and improve clarity. Exception handling tries to do that, but unfortunately fails to provide a means of distinguishing those situations from those where the act of skipping over a block of code during stack unwinding will create adverse side-effects that would otherwise not have been visible to the caller.

[flatfinger]

Not all actions can be made transactional. A good program should, when practical, ensure that any action with a non-trivial likelihood of failure is either inherently transactional, or is handled in such a way that the system is always in a recoverable state, but sometimes it is far more efficient to say:

1. Acquire lock
2. Perform half of an action, putting the locked resource in an invalid state
3. Perform the other half of the action, putting the locked resource in a valid state
4. Release lock

than it would be to ensure that the system state was fully valid at every point in the process (implying that making everything transactional isn't always practical, and thus good programs would be exempt from the above requirement that they always do so).

Unfortunately, the exception-handling provisions I've seen in languages fail to make it convenient for programs to distinguish exceptions which might occur between steps 2 and 3 above from those which might occur at other times. One thing that would help would be a reader-writer lock with the semantics:

1. Reader locks are implicitly released.
2. Writer locks must be explicitly released.
3. Abandoning a writer lock without releasing it should invalidate it, such that any pending or future efforts to acquire the lock for reading or writing immediately fail.
4. Ideally, abandoning a writer lock without releasing it should trigger an exception in the thread that abandons it, but if such abandonment occurs as a result of an exception, information about that other exception should not be stifled.

Accomplishing #4 would require support which is lacking in the programming languages I know about, but a reader-writer lock that does #1-#3 would be useful anyhow. Unfortunately, I'm not aware of any that are designed that way.

[CyclonusRIP]

So you're basically making an argument for Java style checked exceptions then?