> -----Original Message-----
> From: Bernard James POPE [mailto:[EMAIL PROTECTED]]
> Sent: Tuesday, July 04, 2000 9:55 AM
> To: [EMAIL PROTECTED]
> Cc: [EMAIL PROTECTED]
> Subject: re: Proposed change to various exception-related names
>
>
> On the topic of exceptions in GHC,
>
> Section 3.7 of the Haskell Libraries document (on the ghc
> website) says:
>
> "Note: GHC currently doesn't generate the arithmetic or the async
> exceptions."
>
> This still seems to be the case in 4.09
>
> Does it implement the "NonTermination" exception? Or perhaps
> what I should ask
> is: does the "NonTermination" exception correspond to black
> hole detection.
Yes.
> If I have:
>
> catchAll (show (let bot = bot in bot::Int)) (\x -> return (show x))
show isn't strict, so in fact the exception is being raised but outside the
scope of the catchAll.
Try this:
import Exception
main = catchAll (let bot = bot in bot) (\x -> print x)
with 4.08 I get:
$ ./a.out
<<loop>>
> I don't catch the non-termination exception, however I expect
> that I ought
> to.
>
> Perhaps I am misinterpreting this aspect of the exception mechanism.
>
> Also, approximately how far away is the generation of arithmetic and
> asynchronous exceptions?
I haven't looked into arithmetic exceptions yet, but my guess is that it's
going to be pretty tricky to catch the signal and propogate it into an
exception in the correct thread. It's not high up on our priority list at
the moment, mainly because you're the first person to ask for it!
Asynchronous exceptions: we generate stack overflow exceptions at the
moment, and you can send asynchronous exceptions between threads, but we
don't generate HeapOverflow exceptions yet (there was some discussion on
this subject recently on glasgow-haskell-bugs, you should be able to find it
in the archives).
> On a slightly different note I was quite surprised to find that
> (1/0)::Float gave me back a value "Infinity" rather than causing
> an exception to occur. I noticed in the "ArithException"
> data-type that there
> is a constructor "DivideByZero". Is it expected that when arithmetic
> exceptions are implemented (1/0)::Float will throw such an
> exception rather
> than returning "Infinity"?
I believe that the IEEE 754 floating point standard specifies that the
default behaviour for "exceptional" floating point operations is to generate
Inf or NAN, rather than stop the program or raise an exception. I imagine
when we implement arithmetic exceptions we'll make this tunable.
Cheers,
Simon
