I totally support the current implementation, you NEVER want
a program to just terminate. At least you should be able to say
something like "Internal Error" and log it, and then terminate.
/mattias
P.s. I have observed that users really hate internal error
messages, so nowadays I just log the error, and then try to
restart the application. In this way the users will not even
detect that the application failed.
In most cases, they will not report this as an error, they
will just tell you when you ask, that the application behaved
strange, and that they found a workaround.
There exists probably some kind of psychological explanation
for their behaviour. For example that people are used to
that other people sometimes behave strange, like lying,
and they tolerate that. However, people would find it
very strange if instead of answering, you just run away.
> -----Original Message-----
> From: owner-caml-list@pauillac.inria.fr
> [mailto:owner-caml-list@pauillac.inria.fr] On Behalf Of james woodyatt
> Sent: Wednesday, February 20, 2002 5:36 PM
> To: Xavier Leroy
> Cc: The Trade
> Subject: Re: [Caml-list] assert false and -noassert
>
>
> On Monday, February 18, 2002, at 06:00 , Xavier Leroy wrote:
> > [I wrote:]
> >> While we are on the subject of the assert function, it occurs to me
> >> that
> >> it might be nice if -noassert together with "assert false" were to
> >> bypass all exception handling and go right into program
> termination.
> >> It
> >> seems to me that if I've used the -noassert option, I've
> made a promise
> >> that the code compiled with it will never raise the Assert_failure
> >> exception.
> >
> > This is a topic that we've discussed at some point: is it
> appropriate
> > to map (conceptually) fatal errors (such as a failed
> assertion) to an
> > exception? There is one pitfall with this approach, namely that a
> > catch-all "try ... with x -> ..." might inadvertently hide
> the fatal
> > error. On the other hand, the strenght of this approach is that it
> > enables your program to clean up and possibly log a detailed error
> > message before termination.
>
> It *is* appropriate to map conceptually fatal errors (such as failed
> assertions) to exceptions. I have a library. It contains
> assertions.
> I want to test it. I have a list of thirty test functions.
> I iterate
> the list to apply all the functions to test the library,
> wrapping each
> one in a "try ... with x -> ..." clause. Result: all thirty
> functions
> are applied, and I know how many of them raise the Assert_failure
> exception.
>
> At some point, I want to turn off the assertions. My expectation is
> that -noassert would then compile the library so that it never raises
> the Assert_failure exception. Unfortunately, the "assert false" case
> is... well, an exception to the general rule.
>
> That's why, when the -noassert flag is used, I would prefer
> that "assert
> false" map to an immediate program termination, Ã¡ la
> "abort()" in the C
> language. In fact, if that's what ocamlopt inserted in this
> case, i.e.
> a call to abort() in the C library, I would find that optimal.
>
>
> --
> j h woodyatt <jhw@wetware.com>
> "...the antidote to misinformation is more information, not less."
> --vinton cerf
>
> -------------------
> To unsubscribe, mail caml-list-request@inria.fr Archives:
http://caml.inria.fr Bug reports: http://caml.inria.fr/bin/caml-bugs
FAQ: http://caml.inria.fr/FAQ/ Beginner's list:
http://groups.yahoo.com/group/ocaml_beginners
-------------------
To unsubscribe, mail caml-list-request@inria.fr Archives: http://caml.inria.fr
Bug reports: http://caml.inria.fr/bin/caml-bugs FAQ: http://caml.inria.fr/FAQ/
Beginner's list: http://groups.yahoo.com/group/ocaml_beginners