Re: Exceptions

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

Relevant Pages

  • Re: Question concerning object-oriented programming
    ... there has usually been a toString. ... I would prefer an exception thrown. ... Actual programmers are supposed to write code that verifies input. ... Educated middle-class people learn how to use language to ...
    (comp.programming)
  • Re: Structured exception information
    ... the programmers, I don't think that approach will produce good error ... involved in exception raising and exception handling in the ... But when the exceptions were reported as strings into some log ... program and can be arranged for Ada coverage rules. ...
    (comp.lang.ada)
  • Re: Rationale behind unwind-protect and double errors
    ... try/finally exception handling system. ... C++ programmers usually use destructors for the same purpose. ... handling, which does not use the mechanism you outline. ...
    (comp.lang.lisp)
  • Re: c++ documentation
    ... Alternatives to understanding how the language maps onto the metal? ... One can do a lot with C++ without ever using a raw pointer directly if one ... Code that is not exception safe impedes this. ... I do agree that some programmers overuse the ...
    (comp.os.linux.development.apps)
  • Re: DBD::SQLite 1.09 dies if select returns 0 rows
    ... >> the next line causes an exception, ... Oops. ... Seems I wasn't quite awake when I tested that. ... reusing the statement handle with execute and fetchrow_array works ...
    (perl.dbi.users)