[Caml-list] Catching exceptions into strings

[Caml-list] Catching exceptions into strings

[Gaurav Chanda]

Hello

I want to catch exceptions into strings. I do not want to have pre-defined exceptions in my module which can be handled. I want to catch exceptions like "floating point exceptions" etc. 

I wrote the follwing piece of code:

value divide2 p = 2/p ;

value foo p =
        try divide2 p
        with
        [e -> let _ =  do {print_string (Printexc.to_string e);flush stdout} in  9];

value _ = foo 0;

(This code is in the Camlp4 revised syntax).

When I compile and run this code, I get :

Floating point exception


However, after loading OCAML, if I use this file, I get

 value divide2 : int -> int = <fun>
value arbit : int -> int = <fun>
Division_by_zero

That is, in the latter case, I get what I want but in the former case, I don't. Could you help me solve this problem ?

Gaurav







_______________________________________________________
WIN a first class trip to Hawaii.  Live like the King of Rock and Roll
on the big Island. Enter Now!
http://r.lycos.com/r/sagel_mail/http://www.elvis.lycos.com/sweepstakes
-------------------
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

Re: [Caml-list] Catching exceptions into strings

[Xavier Leroy]

> I want to catch exceptions into strings. I do not want to have
> pre-defined exceptions in my module which can be handled. I want to
> catch exceptions like "floating point exceptions" etc.
> 
> I wrote the follwing piece of code:
> 
> value divide2 p = 2/p ;
> 
> value foo p =
>         try divide2 p
>         with
>         [e -> let _ =  do {print_string (Printexc.to_string e);flush stdout} in  9];
> 
> value _ = foo 0;
> 
> (This code is in the Camlp4 revised syntax).
> 
> When I compile and run this code, I get :
> 
> Floating point exception
> 
> However, after loading OCAML, if I use this file, I get
> 
>  value divide2 : int -> int = <fun>
> value arbit : int -> int = <fun>
> Division_by_zero
> 
> That is, in the latter case, I get what I want but in the former
> case, I don't.

ocamlopt-generated code does not turn division by zero into an exception,
like ocamlc-generated code or the toplevel environment do.  Instead,
you just get a hardware signal that kills the ocamlopt-generated program.
See section 11.4 of the OCaml manual for a complete list of
differences between ocamlopt and ocamlc.

- 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

Re: [Caml-list] Catching exceptions into strings

[Michael Vanier]

> Date: Mon, 10 Jun 2002 07:27:15 -0700
> From: "Gaurav Chanda" <gaurav_chanda@lycos.com>
> 
> Hello
> 
> I want to catch exceptions into strings. I do not want to have pre-defined exceptions in my module which can be handled. I want to catch exceptions like "floating point exceptions" etc. 
> 
> I wrote the follwing piece of code:
> 
> value divide2 p = 2/p ;
> 
> value foo p =
>         try divide2 p
>         with
>         [e -> let _ =  do {print_string (Printexc.to_string e);flush stdout} in  9];
> 
> value _ = foo 0;
> 
> (This code is in the Camlp4 revised syntax).
> 
> When I compile and run this code, I get :
> 
> Floating point exception
> 
> 
> However, after loading OCAML, if I use this file, I get
> 
>  value divide2 : int -> int = <fun>
> value arbit : int -> int = <fun>
> Division_by_zero
> 
> That is, in the latter case, I get what I want but in the former case, I don't. Could you help me solve this problem ?
> 
> Gaurav
> 

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?

Mike
-------------------
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

Re: [Caml-list] Catching exceptions into strings

[Guillaume Valadon]

re,

> That is, in the latter case, I get what I want but in the former case, I don't. Could you help me solve this problem ?

The excpetion is only raised when you use bytecode and not with native-code.
See http://caml.inria.fr/ocaml/htmlman/manual025.html, section 11.4

guillaume
-- 
mailto:guillaume@valadon.net
ICQ uin : 1752110

Page ouebe : http://guillaume.valadon.net

     "Everybody be cool. You ... be cool" - Seth Gecko
-------------------
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

Re: [Caml-list] Catching exceptions into strings

[David Chase]

At 11:23 AM 6/11/2002 +0200, Guillaume Valadon wrote:
>The excpetion is only raised when you use bytecode and not with native-code.
>See http://caml.inria.fr/ocaml/htmlman/manual025.html, section 11.4

That's really rather surprising.  Given that the manual recommends that
users explicitly check for zero to avoid this exception, why isn't the
compiler simply inserting the check for them where it happens to be
necessary, and optimizing it out when it is not?  Turning off the
check can be another one of those no-belts-no-bags-no-bumpers compiler
flags that some people are so fond of.

David Chase


-------------------
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

Re: [Caml-list] Catching exceptions into strings

[Xavier Leroy]

> That's really rather surprising.  Given that the manual recommends that
> users explicitly check for zero to avoid this exception

The manual suggests that instead of writing

        try x / y with Division_by_zero -> ...

you could also write

        if y = 0 then ... else x / y

and not only avoid the issue, but end up with clearer code as well.
However, this kind of transformation isn't always applicable.

> , why isn't the
> compiler simply inserting the check for them

This is a reasonable option -- much more reasonable than trying to
intercept the SIGFPE signal and somehow turn it into an exception.
I still have doubts that reporting division by zero via an exception
is really useful, though.

> where it happens to be necessary, and optimizing it out when it is not?

I'm more skeptical here.  I'm yet to see a practical compile-time
analysis that can prove that an integer expression is not zero in any
but the most trivial cases (the expression is a constant or a for-loop
index). (By "integer", I mean machine integers with modulo arithmetic.)

- 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

Re: [Caml-list] Catching exceptions into strings

[David Chase]

At 05:37 PM 6/11/2002 +0200, Xavier Leroy wrote:
>> where it happens to be necessary, and optimizing it out when it is not?
>
>I'm more skeptical here.  I'm yet to see a practical compile-time
>analysis that can prove that an integer expression is not zero in any
>but the most trivial cases (the expression is a constant or a for-loop
>index). (By "integer", I mean machine integers with modulo arithmetic.)

Trivial is pretty common, and for-loop index is an important
common case.  A "constant propagation" lattice can also be a
good deal more interesting than just constants.  I've worked on a
compiler that propagated information about type inference, null/not,
relationship to various array bounds, positive/negative/zero/not,
and a friend and I have discussed the usefulness (not the feasibility,
which is dead-simple) of propagating information about set/cleared/smeared
bits.  It is plausible, if you are working in the absence of reflection,
that a compiler might infer the non-zero-ness of array elements and
object fields.  If, on the other hand, you are working in a world where
programs have reflective access to data, then all bets are off (as in,
once upon a time, and maybe still, the native code in java.lang.sql went
out and fiddled with the private fields of strings, and I know of people
at a Famous Computer Company who wrote native code that twiddled the private
fields of Java file-related classes in order to get a sort of poor man's
asynchronous I/O.).

I've also learned to be incredibly skeptical about
any programmer's assertion that "X cannot possibly happen", and
throwing an exception means that you can at least talk about what
happens when X does happen.  Just for instance, a server program can
be written to catch any exception at the "outside" of a service
thread, and report it both to the web page and the debug log, and
then continue running as before.  This is much better than the server
falling over and needing a restart.

One approach to this problem, though I don't know if anyone has
seriously tried it, would be to ask the programmer to supply the
missing proof steps, and if those steps connect the dots, then the
checks come out.  This does require a cleverer proof engine in the
compiler, but I'd trust that a lot more than just believing some
claim that I read in a comment or a build script.

And lastly, what does it cost to do the check?  Surely, you did not
omit the check in the name of efficiency (he says, smirking) without
first measuring the cost?  That would be (ahem) premature optimization,
which is well-known as the root of all evil.  :-)

David Chase


-------------------
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

Re: [Caml-list] Catching exceptions into strings

[Michael Vanier]

> Date: Tue, 11 Jun 2002 17:37:26 +0200
> From: Xavier Leroy <xavier.leroy@inria.fr>
> 
> > That's really rather surprising.  Given that the manual recommends that
> > users explicitly check for zero to avoid this exception
> 
> The manual suggests that instead of writing
> 
>         try x / y with Division_by_zero -> ...
> 
> you could also write
> 
>         if y = 0 then ... else x / y
> 
> and not only avoid the issue, but end up with clearer code as well.
> However, this kind of transformation isn't always applicable.
> 
> > , why isn't the
> > compiler simply inserting the check for them
> 
> This is a reasonable option -- much more reasonable than trying to
> intercept the SIGFPE signal and somehow turn it into an exception.
> I still have doubts that reporting division by zero via an exception
> is really useful, though.
> 

Why is it unfeasible to intercept the SIGFPE signal?  Those of us who do
numeric computation would really appreciate this capability.

Mike
-------------------
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

Re: [Caml-list] Catching exceptions into strings

[Xavier Leroy]

> And lastly, what does it cost to do the check?  Surely, you did not
> omit the check in the name of efficiency (he says, smirking) without
> first measuring the cost?

The check is omitted in the name of (initial) simplicity of the
ocamlopt code generator, e.g. "for a start, let's map all arithmetic
operations to those of the hardware and see if that's good enough".
I'm not too concerned about the run-time penalty: integer division is
slow even on processors that have it in hardware.

- 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

Re: [Caml-list] Catching exceptions into strings

[Xavier Leroy]

> 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

Re: [Caml-list] Catching exceptions into strings

[Michael Vanier]

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

Re: [Caml-list] Catching exceptions into strings

[John Carr]

> > , why isn't the compiler simply inserting the check for them
> 
> This is a reasonable option -- much more reasonable than trying to
> intercept the SIGFPE signal and somehow turn it into an exception.
> I still have doubts that reporting division by zero via an exception
> is really useful, though.

I don't see the problem with translating SIGFPE into an exception.
The same technique is used for bounds checking.  On SPARC/Solaris
SIGILL becomes an array bounds error.  To handle SIGFPE similarly
requires about five lines of code per platform in asmrun/signals.c
plus about 20 lines of code in asmrun/fail.c to generate the
appropriate exception.

If the language defines a divide-by-zero exception then the runtime
should generate the exception.  I can think of only one reason not
to do so on a platform where division by zero results in a signal:
the core dump may be easier to debug than an uncaught exception.
(How about a stack trace on error for compiled code?)


    --John Carr (jfc@mit.edu)
-------------------
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

Re: [Caml-list] Catching exceptions into strings

[Xavier Leroy]

> I don't see the problem with translating SIGFPE into an exception.
> The same technique is used for bounds checking.  On SPARC/Solaris
> SIGILL becomes an array bounds error.

Correct; same thing for the PowerPC.  However, this is implemented
correctly for 5 Unix variants out of 7 supported for these processors
(I haven't figured out how to do it for SPARC/Linux and SPARC/BSD),
and the implementation is further simplified by the assumption that C
code doesn't contain "trap" instructions.

For division by zero, you need to distinguish between SIGFPE generated
inside or outside Caml code, and get the thing working for about 20
different Unix variants.  Go ahead.

- 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

Re: [Caml-list] Catching exceptions into strings

[Xavier Leroy]

> 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?

ISO C9X (the next generation C standard, not yet implemented by everyone)
provides ways to test for pending floating-point exceptional conditions
(overflows, NaNs, etc).  It does not (AFAIK) standardize an API to
turn some/all of these conditions into signals.

So, once C9X becomes common enough, the bytecode interpreter could
conceptually check after each floating-point operation.  I doubt we'll
ever do this, however, given that the IEEE "no exception" model seems
to become universal, even if you don't like it :-)  (See below.)

> 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.  

It is "caught" not as an exception, but by returning the appropriate
values defined for this very purpose in IEEE arithmetic:
     1.0 / 0.0 = +Inf   -1.0 / 0.0 = -Inf   0.0 / 0.0 = NaN
This might not seem natural to you, but it's the result of years of
arguing among numerical experts, and is the standard towards which
both hardware and programming languages converge.

- 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

Re: [Caml-list] Catching exceptions into strings

[Ken Rose]

Xavier Leroy wrote:

> > 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.
> 
> It is "caught" not as an exception, but by returning the appropriate
> values defined for this very purpose in IEEE arithmetic:
>      1.0 / 0.0 = +Inf   -1.0 / 0.0 = -Inf   0.0 / 0.0 = NaN
> This might not seem natural to you, but it's the result of years of
> arguing among numerical experts, and is the standard towards which
> both hardware and programming languages converge.

I'm shooting from the hip here, having not even looked in the manual,
but a good compromise might be some NaN-to-exception functions that are
identity operations if the parameter is a regular number, but that raise
exceptions if it's )for example) an infinity, or a NaN, or denormal, or
perhaps others.

 - ken
-------------------
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

Re: [Caml-list] Catching exceptions into strings

[John Carr]

> For division by zero, you need to distinguish between SIGFPE generated
> inside or outside Caml code, and get the thing working for about 20
> different Unix variants.  Go ahead.

I implemented Division_by_zero using signals for SPARC/Solaris and
i386/Linux compiled code.  I don't have the resources or motivation
to try 18 other hardware/software combinations.

Anyone who is interested in this feature can email me for source code.

    --John Carr (jfc@mit.edu)
-------------------
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