Re: Exceptions



On Mon, 10 Dec 2007 10:20:38 +0100, Georg Bauhaus wrote:

Do programmers put a block around every procedure call so
that the proper occurence of Constraint_Error is handled?

Yes if Constraint_Error shall not propagate further. What is the
alternative BTW? To say that it does not propagate, but let it do?

Note that to argue against exception contracts on the basis that handling
exceptions is difficult is a fallacy. It is like to argue that
floating-point type is bad because calculating sine is difficult.

And will this likelyhood increase once subp declarations
announce foreseeable exceptions?

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.

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. The goal of software
design is to minimize the damage caused by program execution (the best way
is not to write any programs at all (:-)).

Lesser likelihood of exception propagation is compensated by the damage
inflicted by.

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. I can only say that
contracted exceptions are well in Ada spirit.

This is probably
the reason why people forget to handle exceptions properly. They are not
that visible.

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 have seen a number of null handlers...

My guess is that missing else branches or undocumented null "others"
in case distinctions are a related issue. The issue really is
handling cases, not announcing them. Every if implies the possibility
of an else. Still we can have null else branches (or "others" choises).

No, only in absence of a contract. Consider:

function Foo return ... is
begin
if ... then
return ...;
end if;
end Foo;

This is illegal because of the contract to return a value. I hope you do
not propose to make Foo legal because required "else" would spoil so nicely
formatted code? (:-))

Exception non-propagation contracts fall under this category.

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. Others is harmless if it includes only Blue. It can be damaging
if it does "all other Integers." Ideally the constructs should be as weak
as possible to be able to accomplish the goal. Goto or template solve the
problem but they call the devil who won't go back. So "others" does when it
refers to a set of big cardinality then covered by null-action.

--
Regards,
Dmitry A. Kazakov
http://www.dmitry-kazakov.de
.



Relevant Pages

  • Contracted exceptions for Ada (was: Exceptions)
    ... The ARG has discussed "exception contracts" a couple of times, ... It is not optional it is "any exception may propagate." ... actual pool states themselves will never be checked at run-time (following ...
    (comp.lang.ada)
  • Re: Exceptions
    ... I'm not sure if Dmitry really wants answers to his questions below -- perhaps they were merely rhetorical -- but they tickled my curiosity, so here is one data point from my main Ada application: ... Explicit raise statements (with exception name): ... propagate same application-defined exception: 13 ... But my feeling is that at least half of the handlers are meant to catch exception from calls, and I don't think that there is any systematic difference in the proportion of "eaters" versus "propagators" between the two cases. ...
    (comp.lang.ada)
  • Re: Exceptions
    ... I cant say the same about the codemonkeys I work ... I'd rather let unexpected exceptions propagate to some outer ... I've suggested in the past that a package/suite should only ... What I'd like is to be able to propagate my exception ...
    (comp.lang.ada)
  • Re: Exceptions
    ... one declared exception can be raised in several subprograms, but I think the average number of subprograms that can raise a given application-defined exception is between 1 and 2, not larger, in this application. ... The number of subprograms that can *propagate* a given application-defined exception is larger, but I can't say by how much. ... Several handlers for Constraint_Error "translate" C_E to a more specific exception by raising the specific application-defined exception for handling at higher levels. ...
    (comp.lang.ada)
  • Re: Enumerate question: Inner looping like in Perl
    ... the 'for' statement does not propagate the StopIteration ... That's what the 'else' clause in a 'for' statement is for: ... return or by propagating an exception). ... purpose from "Python in a Nutshell", ...
    (comp.lang.python)