Re: Exceptions

[Robert A Duff <bobduff@shell01.TheWorld.com>]

Maciej Sobczak <see.my.homepage@gmail.com> writes:

> On 13 Gru, 14:40, Robert A Duff <bobd...@shell01.TheWorld.com> wrote:
>
>> The solution to "when others => null;" and the like is better
>> education.
>
> Isn't it also a solution for all the presumed problems of C/C++?
> Sorry, could not resist. ;-)

I see the smiley, but...  Here's a serious reply anyway:

A language design should not try to prevent people from
doing bad things.  It should try to prevent people from
doing bad things BY ACCIDENT.

The Java programmers who have been mentioned several times in this
thread -- the ones who evilly stick in do-nothing handlers -- are doing
so on purpose.  Any attempt to fix that problem via language design will
backfire.  Fixing it via education OTOH has a good chance of success.

Forgetting to handle an exception, however, is an accident.  A language
design can help there, but education will not.

>> I don't consider Constraint_Error "mere", by the way.
>> It almost always represents a bug.
>
> What about a situation when a user entered an input data that was
> outside of legal (and documented) range? Or that caused our of range
> value further down the pipe?
> This is not necessarily a bug, just an indication that the value is
> out of range. The exception can help to come back to the input loop
> and repeat the user scenario, abandoning all the state that was
> created in the meanime. This way the program does not enter into any
> abnormal state.

Well, you can't refute an "almost always" statement by giving a
counterexample.  ;-)

Yes, in the situation you mention, it's reasonable to say:

    when Constraint_Error =>
        null; -- loop back and ask user again

I've got no problem with that, so long as there's a good comment.
It should not be "when others" in this case, either.

>> There ought to be a standard predefined procedure for stopping the
>> program "on the spot".  Since there isn't, you can import "exit".
>
> I was wandering whether there is any standard mechanism for this.

You can abort the environment task.  But I'm not sure what that will do
in a multi-threaded, multi-language program -- depends on the
implementation.  Anyway, it's an ugly trick.  I'd rather be able to
portably say "Kill_Program;" or "Kill_Program(exit_code);" or something
like that.  Note that you need to think carefully about whether you want
finalizers to run.

- Bob