Le 29/10/2024 à 21:15, karl@??? a écrit :
> Didier:
> ...
>>     This discussion has been very usefull, at least to me because it
>> helped me to narrow down my concern about exception handling. Here it is.
> Nice, that is good, happy to argue with you in a friendly manner.
    Yes (~:
>>     First: exception does not mean only exceptions detected by the OS
>> or the hardware,
> Isn't "exception" a ADA/C++/etc. construct, and the HW can react to
> thing with traps, interrups, error returns, and the OS, well it depends
> on the OS, but in the case of unix like systems, it returns error values
> and possible signals, which is handled by the c library and then by
> the ada runtime library which converts the above things to exceptions.
> And if I'm right, the exceptions arn't detected by the OS or the HW,
> but by the Ada runtime lib linked to the executable. Well that is how
> I understand it at least.

>> but includes those cases detected by the program itself.
> Do you mean detected by the Ada runtime lib, or the thing when you
> "raise" an exceptions in the code ?

Both. You can raise exceptions. Including exceptions of your own.

> The are no "exceptions" in C so it cannot propagate them, I guess you
> mean various error conditions, handled in C with return/parameter values
> at the return of a function/subroutine or by a signal.

    That's exactly the point. In Ada or C++, you can decide that a
situation is /exceptional/ and you want to process it in a different
logical flow than the /normal/ one, either in the same subprogram, or
anywhere back in the call chain, actually at the very place it makes
sense to catch it. In C, when you detect an exceptional situation, you
haven't much other choices than advertise it to the caller by the return
value and propagate it through the return values of all the functions in
the call chain back to the function in which you want to process it. And
this means that, in all the call chain, every function call must be
followed by a test of the return value with a conditional branching,
just to ensure this propagation. One can think that people want to get
rid of this check by lazzyness, but it is actually to make the program
simpler and easier to read.

    If you have a look at setjmp/longjmp, you'll see its main use case
deals exactly with that problem, but it is delicate to use.

    My current work is a parser for the web client request and MIME
header fields. It's complicated because the syntax of MIME header fields
has several variations depending on the field name. It parses it with a
collection of functions at various levels of abstraction, but, if an
unexpected character or a disconnection is detected at some level, the
program needs to propagate that error almost back to the main program:
obviously it makes no sense to continue parsing, and, in case of
disconnection, the socket must be closed and a new one accept()ed. The
program would better jump there directly so that the intermediate
functions might just ignore it. These exceptions never happen, but, in
theory, they could; that's a good reason to call them exceptions.

--     Didier