On Mon, Sep 10, 2012 at 3:05 PM, Peter Simons wrote:
> Hi,
>
> 'extensible-exceptions' used to be a part of GHC, but it appears that
> the package has been dropped from 7.6.1. Yet, the release notes on
> haskell.org don't say anything about this subject (other than TODO).
>
> Was that change inten
Hi,
'extensible-exceptions' used to be a part of GHC, but it appears that
the package has been dropped from 7.6.1. Yet, the release notes on
haskell.org don't say anything about this subject (other than TODO).
Was that change intentional?
Take care,
Peter
__
On Sun, 23 Nov 2008, Duncan Coutts wrote:
On Sun, 2008-11-23 at 01:40 +0100, Henning Thielemann wrote:
On Sat, 22 Nov 2008, Thomas Schilling wrote:
It's a pattern match error, implemented by throwing an asynchronous
exception. The idea being, that we only have one mechanism (well, an
synchr
BTW, the documentation of catch is bad: the example
catch (openFile f ReadMode)
(\e -> hPutStr stderr ("Couldn't open "++f++": " ++ show e))
does not type check. Is this a known "bug" or shall I report it anywhere?
Regards,
Martin.
Ross Mellgren schrieb:
I think catch is now basica
On Sun, 2008-11-23 at 01:40 +0100, Henning Thielemann wrote:
> On Sat, 22 Nov 2008, Thomas Schilling wrote:
>
> > It's a pattern match error, implemented by throwing an asynchronous
> > exception. The idea being, that we only have one mechanism (well, an
> > synchronous exceptions, thrown via thr
On Sat, 22 Nov 2008, Thomas Schilling wrote:
It's a pattern match error, implemented by throwing an asynchronous
exception. The idea being, that we only have one mechanism (well, an
synchronous exceptions, thrown via throwIO).
Yes, I know that there's a difference between "error" and "excepti
It's a pattern match error, implemented by throwing an asynchronous
exception. The idea being, that we only have one mechanism (well, an
synchronous exceptions, thrown via throwIO).
Yes, I know that there's a difference between "error" and "exception",
but I would argue that which is which depend
On Sat, 22 Nov 2008, Thomas Schilling wrote:
Be careful, though. This only works if there's a single constructor
for your exception type. If there are multiple, you should write it
like this:
thing_to_try `catch` \(e :: MyErrorType) -> case e of MyError1 _ ->
..; MyError2 _ -> ...
If you wr
On Sat, 2008-11-22 at 15:27 +, Thomas Schilling wrote:
> >*Main> tryJust errorCalls $ print $ [] !! 23
> >tryJust errorCalls $ print $ [] !! 23^JLeft Prelude.(!!):
> index
> >too large
> >
> >*Main> tryJust errorCalls $ print $ throw NonTermination
> >try
2008/11/22 David F. Place <[EMAIL PROTECTED]>:
> On Sat, 2008-11-22 at 11:33 +, Thomas Schilling wrote:
>> Be careful, though. This only works if there's a single constructor
>> for your exception type. If there are multiple, you should write it
>> like this:
>>
>> thing_to_try `catch` \(e :
On Sat, 2008-11-22 at 11:33 +, Thomas Schilling wrote:
> Be careful, though. This only works if there's a single constructor
> for your exception type. If there are multiple, you should write it
> like this:
>
> thing_to_try `catch` \(e :: MyErrorType) -> case e of MyError1 _ ->
> ..; MyErr
Be careful, though. This only works if there's a single constructor
for your exception type. If there are multiple, you should write it
like this:
thing_to_try `catch` \(e :: MyErrorType) -> case e of MyError1 _ ->
..; MyError2 _ -> ...
If you write `catch` (MyError1 ...) and a MyError2 is thr
I think catch is now basically what catchJust was -- you can just do
> thing_to_try `catch` (\ (ErrorCall s) -> putStrLn s)
and it will only catch ErrorCall exceptions.
-Ross
David F. Place wrote:
Hi, All.
I am trying to understand the new exceptions package in base-4
Control.Exceptions. T
Hi, All.
I am trying to understand the new exceptions package in base-4
Control.Exceptions. The documentation for catchJust is the same as in
Control.OldException including this example:
result <- catchJust errorCalls thing_to_try handler
Control.OldException provides the predicate errorCalls,
14 matches
Mail list logo
