From: Michael Vanier <mvanier@cs.caltech.edu>
To: xavier.leroy@inria.fr
Cc: gaurav_chanda@lycos.com, caml-list@pauillac.inria.fr
Subject: Re: [Caml-list] Catching exceptions into strings
Date: Wed, 12 Jun 2002 02:36:54 -0700 [thread overview]
Message-ID: <200206120936.g5C9asB18950@orchestra.cs.caltech.edu> (raw)
In-Reply-To: <20020612105308.B29875@pauillac.inria.fr> (message from Xavier Leroy on Wed, 12 Jun 2002 10:53:08 +0200)
Xavier,
Thanks for the clear explanation of a topic that always puzzled me.
Personally, I could live with SIGFPE just aborting the program. I'm also
curious: is it possible to catch floating point errors in ocaml's bytecode?
Or is this, too, dependent on the ansi C/Posix standards? I tried this
with java and was interested to find that integer division by zero is
caught but floating point division by zero isn't.
<off-topic>
Given all this, I wonder how C# handles "checked arithmetic"? Are the
rules different on Windows?
</off-topic>
Mike
> Date: Wed, 12 Jun 2002 10:53:08 +0200
> From: Xavier Leroy <xavier.leroy@inria.fr>
>
> > Hmm. I didn't think it was possible to catch floating point exceptions in
> > ocaml (something I'd very much like to be able to do). Why doesn't ocaml
> > support this? Or does it?
>
> Your question requires a bit of decoding.
>
> Floating-point operations in OCaml follow the IEEE-standard usage of
> never causing an exception, but return infinities or (silent) NaNs
> when something is weird.
>
> The "Floating point exception" you saw in Gaurav's message is a
> misnomer: *integer* division by zero generates a SIGFPE signal
> under Unix, which is printed as "Floating-point exception" but
> really means "Integer arithmetic exception".
>
> Most processors (and I believe the IEEE standard) offer the option
> to raise exceptions instead of returning NaNs, infinities or denormals.
> This facility is not available from OCaml because it's not provided
> by ANSI C nor by POSIX, which are essentially what the OCaml runtime
> system is building upon.
>
> Even then, you'd get a SIGFPE when a floating point operation goes bad,
> and we're back to the issue of mapping a Unix *synchronous* signal to
> a Caml exception. (Asynchronous signals are already dealt with.)
> It can be done, although not trivially. But the main issue here is to
> get enough context about the signal. Raising Division_by_zero every
> time SIGFPE is received is not correct: maybe someone did "kill -FPE <pid>"
> from the outside; maybe the SIGFPE was generated inside a C library
> linked with the Caml code, and which has its own rules for dealing
> with it.
>
> In other terms, what is needed is to collect enough context on the
> SIGFPE occurrence to 1) make sure it's an integer division operation
> that failed, and 2) make sure this happened in OCaml code; only then
> we could generate a Division_by_zero exception. But of course
> there is no portable way to do all this under Unix.
>
> In summary: you can get SIGFPE, but they can only stop your program,
> handling them as exceptions is just not possible.
>
> - Xavier Leroy
>
>
-------------------
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
next prev parent reply other threads:[~2002-06-12 15:27 UTC|newest]
Thread overview: 16+ messages / expand[flat|nested] mbox.gz Atom feed top
2002-06-10 14:27 Gaurav Chanda
2002-06-10 15:07 ` Xavier Leroy
2002-06-10 21:57 ` Michael Vanier
2002-06-12 8:53 ` Xavier Leroy
2002-06-12 9:36 ` Michael Vanier [this message]
2002-06-17 12:48 ` Xavier Leroy
2002-06-17 16:10 ` Ken Rose
2002-06-11 9:23 ` Guillaume Valadon
2002-06-11 13:28 ` David Chase
2002-06-11 15:37 ` Xavier Leroy
2002-06-11 17:44 ` David Chase
2002-06-12 8:33 ` Xavier Leroy
2002-06-11 21:19 ` Michael Vanier
2002-06-14 21:23 ` John Carr
2002-06-17 12:31 ` Xavier Leroy
2002-06-17 21:08 ` John Carr
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=200206120936.g5C9asB18950@orchestra.cs.caltech.edu \
--to=mvanier@cs.caltech.edu \
--cc=caml-list@pauillac.inria.fr \
--cc=gaurav_chanda@lycos.com \
--cc=xavier.leroy@inria.fr \
/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