
1. Can exceptions be used in "pure" functions (outside of monads?)
Exceptions can be thrown from pure functions, and can be used exactly like in the OCaml example (but in Haskell syntax) Exceptions can only be caught in the IO monad.
2. How are these exceptions caught and handled aside from using bracket?
bracket, catch, catchIO
3. Can I define my own exception types?
There is a User exception type, I don't think you can define your own completely new exception type.
4. Can I write code that can catch and handle multiple different exception types from a single block of code?
Yes but see (1) only in the IO monad
5. Is there anything different about working with exceptions in monads?
No.
6. Can I get a stack trace from ghc or hugs if an exception is never caught and thus causes the program to terminate?
Stack traces in lazy laguages are not very useful. Best work-around is to produce an explicit call trace by inserting prints into functions... obviously this requires the functions to be in the IOMonad. Things are still odd because of lazyness though. Keean.

On Friday 01 October 2004 10:57 am, MR K P SCHUPKE wrote:
1. Can exceptions be used in "pure" functions (outside of monads?)
Exceptions can be thrown from pure functions, and can be used exactly like in the OCaml example (but in Haskell syntax)
Can you give me a quick example of how exactly I would do that? I'm trying to understand the ghc docs and not quite making it. Thanks! -- John

6. Can I get a stack trace from ghc or hugs if an exception is never caught and thus causes the program to terminate?
Stack traces in lazy laguages are not very useful. Best work-around is to produce an explicit call trace by inserting prints into functions... obviously this requires the functions to be in the IOMonad. Things are still odd because of lazyness though.
I don't think this is completely true. What typical Haskell compilers have on their stack is not especially useful because it reveals the context in which something was being evaluated and will depend on details of the compiler, what optimizations it performs, etc. But, being able to see the context in which a thunk was constructed would be extremely useful. Such a context would be more or less equivalent to the context (or 'stack dump') printed when the same program is evaluated strictly - by a Caml compiler, say. I think the York folk have the best story on stack traces - I don't know if non-deterministic exceptions have been integrated into their system - probably so. -- Alastair Reid
participants (3)
-
Alastair Reid
-
John Goerzen
-
MR K P SCHUPKE