>
> I could get on board with the idea that we should discourage people from
>>> using exception handling in situations where return codes would be a
>>> *better* solution but you have not established that return codes are *almost
>>> always better* than exceptions for *almost all programmers*. This is
>>> quite different from the situation with smart pointers versus manual memory
>>> management.
>>>
>>
In general, yes, I agree with you, but I do not understand then why
expected<> is not still in the standard.

Note also that the question of the probability of the "exceptional" events
>> occurring is not relevant here, except perhaps in a performance-sensitive
>> context. Whether you want to make that iterator throw an exception on an
>> I/O error, or return expected<char, E>, regardless of the fraction of the
>> time that the error path is taken, is a stylistic choice.
>>
>
Yes and no. By saying "*use exceptions for exceptional situations*" you
inevitably have to answer the question "What are exceptional situations?".
While saying "everything is just a status of execution of a command - it
may be successful, it might be partially successful, it may fail and so
on..." - you do not have to answer this question. Which makes understanding
more easier.


> In addition - as someone who has worked on a code base where exceptions
>> are banned - I have to say that I don't buy the "exceptions lead to crashes
>> in production" logic. If an exceptional condition occurs, then either you
>> know how to handle it, or you don't. In the case where you don't, what
>> happens when you get the error code you don't know how to handle?
>>
>
My point is that (careful using) error-codes can prevent this *completely*.
Here is an excerpt from my comment
<https://www.reddit.com/r/cpp/comments/cliw5j/should_not_exceptions_be_finally_deprecated/evw27oo/?utm_source=share&utm_medium=web2x>
:

   - If you are not interested in details (=> you cannot handle it), you
   just check bool Ok/NotOk. In case of newly added error-code nothing happens.
   - If you are interested in details (=> you are probably trying to handle
   an error), *compiler will issue <https://godbolt.org/z/meed2f> a
   warning/error*: *warning: enumeration value 'NewError' not handled in
   switch*.


The idea that at least with return codes, you can know at compile time that
>> there's something you haven't accounted for, is interesting but I believe
>> it has its issues as well. There will be cases where sloppy programmers
>> will just write a `default:` that propagates the error code (which is
>> equivalent to not handling an exception), or which logs the error and then
>> swallows it (which is equivalent to `catch (...) {}`, but by definition,
>> you cannot know whether this is a sensible thing to do or whether it is
>> necessary to crash the program).
>>
>
Yes, sure, but my point is that if you are using error-codes (even though
it might be difficult), it is *possible* with the help of compiler not to
forget to handle an error: it is either in the signature of a function
(expected<,>) or a field in a enum was added (look at the beautiful warning
above!). While if you are using exceptions, it becomes impossible - *you do
not have any tools* that could, for each line of code, say which exceptions
can be there. How, for example, can you be sure that each and every thrown
exceptions in you entire database is handled exactly where it must be
handled?


Having said that, I understand that, probably, there might be a place for
exceptions, what I do not understand, is that why expected<> is not in the
standard yet - it looks as a perfect complement for exceptions.