Re: Exceptions

[Georg Bauhaus <rm.tsoh+bauhaus@maps.futureapps.de>]

Dmitry A. Kazakov wrote:

In my view, a language feature is useful if and only if it
actually helps reducing the number of bugs.


>>> 2. How often does a caller "eat" an exception of the callee instead of
>>> propagating it further? My guess is 1 / 10.
>> Are you assuming current rules for guessing 10% exception handling,
>> i.e., no exceptions are announced by the subprogram declaration?
> 
> I meant that an exception is typically propagated out of 10 scopes before
> it gets handled.

And?

I/O should be counted separately; Using exceptions to signal invalid
input to some procedure way up the call stack is indeed not a good
idea; in fact, DbC warns you that DbC is not at all about invalid
input.

>>> There is not that many handlers in a good designed code.
>> Hear, hear. [Q] Why do we need more exception announcements, then?
> 
> Because of the damage an unhandled exception does.

I don't buy this. Sure, if your program has effects when
it continues computing using erroneous values, it may damage things;
but this case seems contrued like its counterpart: that in S1; S2;,
S1 fails. This failure need not have an effect on S2!


>> Will design improve because of subp with exception announcements?
> 
> This is a different question. Clearly any language change has certain
> effect on the programming practices and average design. I cannot foresee
> how contracts would influence us, programmers.

The question, 'How does a language feature affect programs?'
is all that matters because programs are produced by writing
them in the programming language with a certain set of features.


 > I can only say that
> contracted exceptions are well in Ada spirit.

Recently, I've read here on c.l.ada that there is Ada
and Ada in the presence of exceptions...


>> If programmers do not handle exceptions properly when they
>> do not see them in source, will forcing them to handle exceptions
>> make them handle exceptions _properly_?
> 
> Exactly so. They still will have an option to keep on ignoring exceptions.
> Only if they will announce the program as exception E free, only then, they
> will be forced to take care of E. Looks reasonable to me.

I suggest you look at some Java code, then. It might change
your perspective on programming (not necessarily Java's fault).


>> If only the Algol symbol "comment" had been given more emphasis
>> in successor languages. A friendly tell-us-what-you-think!
>> mechanism is better IMHO than a combination of force together with a
>> force absorbing mechanism! (Exception "contracts" together with
>> null handlers and the like.)
>>
>>    case Traffic_Light is
>>       when Red => ... ;
>>       when Green => .... ;
>>       when others =>
>>          comment No comment;
>>          null;  -- forces the comment.
>>          -- Hypothesis: the comment "No comment" will not
>>          -- pass quality control
>>    end case;
>>
>> Remove "others" from the languge? :-)
> 
> The problem here is not others. The problem is the power of a language
> construct.

Again, the construct gets its effective power from the
programmer who uses it. It does not matter that you _can_
"write Fortran in any language"; what _will_ non-theorist
programmers actually do?

Therefore, a construct should be such that typical use of the
construct will help normal programmers writing reasonably good
programs. (For me this includes being able to understand and change
the program without a PhD in CS.)

Here is an example of why I think that treating exceptions
like another formal "flow" of control is not going to work
in any practical sense.

packge Subsys is

    Oops: exception;  -- minor hickup
    Argh: exception;  -- Can't go on

    An_Error_Has_Occured: exception;

    type S is tagged null record;  -- parent
    Null_S: constant S;

end Subsys;

package Subsys.P is

    type T is new S with null record;

    function F(X: in out T) return T raise Argh;

end Subsys.P;

package Subsys.Q is

    type T is new S with null record;

    procedure G(X: in out T) return T raise Oops;

end Subsys.P;

with Subsys;
procedure Job raise Subsys.An_Error_Has_Occured;
   -- client


with Subsys.P, Subsys.Q;
procedure Job is
    use Subsys;
begin
    L: declare
       Result : S'class := Q.G(P.F(Null_S));  -- HERE
    begin
       -- ... actions
       null;
    end L;
exception
    when Oops =>
       -- Oops is o.K., our software is robust
       null;
    when Argh =>
       raise An_Error_Has_Occured;
end Subsys.Job;

Now the programmers writing Subsys.P and Subsys.Q decide to
switch the exceptions raised by F and G respectively.
There is a chance that Job won't need a different handler
because the set of exceptions to be handled
has not changed: {Oops, Argh}.
But the meaning of the exceptions has changed significantly,
Oops is now the exception that must be handled but it isn't ...

I don't see an improvement so far.

So we need a different program! One that enables the compiler
to notice that the exception announcements have been changed.

with Subsys.P, Subsys.Q;
procedure Job_Alt is
    use Subsys;
begin

    -- Split   Q.G(P.F(Null_S));  into constituent parts
    -- so that the compiler can differentiate by exception

    Handle_G_Exception: declare
       F_Result : S'class := P.F(Null_S);
    begin
       L: declare
          G_Result : S'class := Q.G(F_Result);
       begin
          -- ... actions
          null;
       end L;
    exception
       when Oops =>
          raise An_Error_Has_Occured;
    end Handle_G_Exception;

exception  -- occurence likely raised by P.F
    when Argh =>
       -- Oops (refactoring missed the name change)
       -- is o.K., our software is robust
       null;
end Job_Alt;

If this style becomes customary for the proper handling of

    Q.G(P.F(Null_S));

then I'm not sure that announcing exceptions alone is that
useful a language change.  The example given makes me assume that
the increase in SLOC count is opening doors to another row of
error candidates.

The requires/modifies/ensures model seems more practical to
me.  It doesn't force handling exceptions; still many programmers
using that model seem to be writing preconditions at least.