caml-list - the Caml user's mailing list
 help / color / mirror / Atom feed
From: Chet Murthy <murthy@pauillac.inria.fr>
To: Christophe Raffalli <cr@dcs.ed.ac.uk>
Cc: Chet.Murthy@inria.fr, Judicael.Courant@lip.ens-lyon.fr,
	caml-list@margaux.inria.fr
Subject: Re: Irrelevant variables in patterns
Date: Sat, 28 May 1994 12:43:29 +0200	[thread overview]
Message-ID: <29438.770121809@pauillac.inria.fr> (raw)
In-Reply-To: Your message of Sat, 28 May 1994 11:36:02 -0000. <13319.9405281036@colonsay.dcs.ed.ac.uk>


>>>>> On Sat, 28 May 1994 11:36:02 -0000, Christophe Raffalli <cr@dcs.ed.ac.uk> said:

>>>La solution serait plutot de fournir un warning lorsque l'on
>>>capture toutes les exception, car cela est un bug dans 99% des cas
>>>(on ne veut pas attraper Catch_break ou Out_of_memory en general).

>But that doesn't work if I have 10 different exceptions in my program
>- I am unwilling to write 10-way branches, as are most programmers.

>Exceptions in ML are a programming mechanism.  They are not used
>anymore for exceptional conditions.  We need a new mechanism for
>that.

	CR> Ok, but as long as "Out_of_memory" and "catch_break" are
	CR> exceptions, if you don't write the ten cases, this is likely
	CR> to be a bug !!

Actually, that's not the case.  Often, I write:

try blablab with (E1(x,y,z)) -> code1
               | (E2(x,y,z)) -> code2
               | e -> handle_exceptions_generally e
;;

Now, that code ought to be written without consideration for things
like Out_of_memory.  Its like writing code in C to do signals.  If you
don't _explicitly_ mess with SIGSEGV, you can't screw yourself.

Moreover, even if I _do_ write the code in handle_exceptions_generally
to treat Out_of_memory, etc, I get many warnings telling me that I am
catching the exception.

The fact that there isn't a separation of exceptions into classes
really limits their usefulness.  At least, we need two classes -
"signals" and "exceptions".  "signals" would be thing which you have
to register global handlers for.

	CR> Furthermore, I just asked for a warning ! this would catch the
	CR> attention of the programmer on a likely bug. but if he knowns
	CR> what he is doing, he is free to do so.

Superfluous warning confuse the programmer, and cause him to disregard
the warnings completely.  Which can cause him real pain when it was a
warning that he should have heeded.

--chet--




  reply	other threads:[~1994-05-30  9:19 UTC|newest]

Thread overview: 16+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
1994-05-26 13:03 Judicael Courant
1994-05-27 18:01 ` Christophe Raffalli
1994-05-28 10:16   ` Chet Murthy
1994-05-28 10:36     ` Christophe Raffalli
1994-05-28 10:43       ` Chet Murthy [this message]
1994-05-28 11:01         ` Christophe Raffalli
1994-05-28 11:05           ` Chet Murthy
1994-05-28 11:09             ` Christophe Raffalli
1994-05-28 11:08         ` Christophe Raffalli
1994-05-28 11:12           ` Chet Murthy
1994-05-30 14:49         ` John Harrison
1994-05-30 18:20           ` calla
1994-05-30  8:53 ` Xavier Leroy
1994-05-30 17:57   ` Christophe Raffalli
1994-05-27 18:58 Damien Doligez
1994-05-30 13:15 Judicael Courant

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=29438.770121809@pauillac.inria.fr \
    --to=murthy@pauillac.inria.fr \
    --cc=Chet.Murthy@inria.fr \
    --cc=Judicael.Courant@lip.ens-lyon.fr \
    --cc=caml-list@margaux.inria.fr \
    --cc=cr@dcs.ed.ac.uk \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).