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.

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

https://docs.adacore.com/gnat_ugx-docs/html/gnat_ugx/gnat_ugx/the_gnat_configurable_run_time_facility.html#the-gnat-configurable-run-time-facility
https://docs.adacore.com/gnat_ugx-docs/html/gnat_ugx/gnat_ugx/gnat_runtimes.html

> 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 ?

>     Second: the concern is not the detection of the exceptions but
> their propagation. In C, appart from using setjmp/longjmp, the only way
> for a callee to propagate an exception is to let the caller re-detect it
> from either the return value or a modified variable. This re-detection,
> repeated at every level of caller, is intermixed by design with the
> logic of normal operation. This goes against program readability; and
> this is my major concern.

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.

Regarding readability:
1, "Debugging is twice as hard as writing the code in the first place.
Therefore, if you write the code as cleverly as possible, you are,
by definition, not smart enough to debug it."
-- Brian W. Kernighan

2, if your function spans more than a screenful, the readability will
go down.

3, don't use more api's than you hopefully know by heart.

4, learn to look past the language clutter, like "{" in c, "begin" in
pascal/ada, "(" in lisp, etc.

And as Kevin wrote, the unhappy path might be iimportant.

Also, we are all different, and any language can be misused to create
bad code.

Regards,
/Karl Hammar