1254389201.7656.3.ca...@localhost
Content-Type: text/plain; charset=Windows-1252
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
On Thu=2C 2009-10-01 at 03:29 +=2C Brian Bloniarz wrote:
I.e. why does an exception raised during exception handling get
propagated past the
Sorry for the garbled post, this should hopefully be plain text:
On Thu, 2009-10-01 at 03:29 +, Brian Bloniarz wrote:
I.e. why does an exception raised during exception handling get
propagated past the exception that triggered the handler?
Because it's the obvious and sensible thing to
Exception handling code should generally be assumed to work, so if
something goes wrong there you would normally like to know about it.
Also, there is nothing preventing you from wrapping the rescue code in
further exception handling, however, if the initial error were raised
upon encountering a
On Thu, 2009-10-01 at 03:29 +, Brian Bloniarz wrote:
I had a question about onException friends: what's the rationale
for having:
(error foo) `onException` (error bar)
give bar and not foo?
I.e. why does an exception raised during exception handling get
propagated past the exception
I had a question about onException friends: what's the rationale
for having:
(error foo) `onException` (error bar)
give bar and not foo? I.e. why does an exception raised during
exception handling get propagated past the exception that triggered
the handler?
Most examples I can think for
On Wed, Sep 17, 2008 at 09:54:13PM -0700, Ryan Ingram wrote:
Better is this:
data MalformedAddressException = MalformedAddressException String
deriving (Show, Typeable)
throwDynIO x = throwIO (DynException $ toDyn x)
You are right.
Anyway the DynException will not be needed in the future
On Sun, Jul 27, 2008 at 07:23:14PM +0200, Adrian Neumann wrote:
Hello,
I think it'd be nice if the compiler could warn me if there are any
exceptions which I'm not catching, similar to checked exceptions in Java.
Does anyone know of a possibility to do that in Haskell?
He, I have
Better is this:
data MalformedAddressException = MalformedAddressException String
deriving (Show, Typeable)
throwDynIO x = throwIO (DynException $ toDyn x)
-- in inet_error
... throwDynIO (MalformedAddressException blah blah) ...
-- in HAppS-Server
... Exception.catchDyn (inet_addr uri)
On Sun, 27 Jul 2008, Adrian Neumann wrote:
Hello,
I think it'd be nice if the compiler could warn me if there are any
exceptions which I'm not catching, similar to checked exceptions in
Java. Does anyone know of a possibility to do that in Haskell?
Please refer to the long extensible
Hello,
I think it'd be nice if the compiler could warn me if there are any
exceptions which I'm not catching, similar to checked exceptions in
Java. Does anyone know of a possibility to do that in Haskell?
Adrian
PGP.sig
Description: Signierter Teil der Nachricht
I don't really think this is possible: consider asynchronous
exceptions and throwTo.
http://www.haskell.org/ghc/docs/latest/html/libraries/base/Control-Exception.html#v%3AthrowTo
Since it can throw just *any* exception into thread. And this thread
might not be aware that anyone can throw him
aneumann:
Hello,
I think it'd be nice if the compiler could warn me if there are any
exceptions which I'm not catching, similar to checked exceptions in
Java. Does anyone know of a possibility to do that in Haskell?
Adrian
You could provide exception-safe wrappers for the functions
[+RTS -xc]
A major problem with this that I notice is that it dumps the stack
whenever any exception is raised, which is a big pain if your program
does IO and regularly raises and catches exceptions as part of normal
operation. A big improvement would be to only dump the backtrace if the
PROTECTED]
| Cc: [EMAIL PROTECTED]; [EMAIL PROTECTED]
| Subject: Re: [Haskell-cafe] Exceptions
|
| But, being able to see the context in which a thunk was constructed
would be
| extremely useful.
|
| Yes of course... I was thinking along the lines of what is possible,
rather
| than what is desirable
On Mon, Oct 04, 2004 at 09:30:22AM +0100, Simon Peyton-Jones wrote:
Actually GHC does exactly that when you compile with -prof -auto-all.
Then if you run with +RTS -xc, you get a backtrace of sorts. (I have
not tested this recently!) The backtrace is not yet reified into a data
structure
I'd be cautious about using exceptions too liberally. When I implemented
a Haskell equivalent to traceroute, I wanted to stop sending packets
when a certain condition occurred. It was very tempting to throw an
exception and catch it at the top level. However, I think the code below
is easier
One of the most important features of a modern language is, to me,
exceptions. I have found very little coverage of exceptions in Haskell,
what what coverage there was seemed to be centered on I/O.
One reason I'm asking is this: what to do when pattern matching is
incomplete due to an error.
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
On Fri, 1 Oct 2004, John Goerzen wrote:
1. Can exceptions be used in pure functions (outside of monads?)
No. The Maybe and Either types may make for viable replacements though.
--
[EMAIL PROTECTED]
___
Haskell-Cafe mailing list
[EMAIL PROTECTED]
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
John Goerzen [EMAIL PROTECTED] writes:
1. Can exceptions be used in pure functions (outside of monads?)
For the theoretical background of this, see A Semantics for Imprecise
Exceptions http://citeseer.ist.psu.edu/196569.html.
--
__( Marcin Kowalczyk
\__/ [EMAIL PROTECTED]
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
On Friday 01 October 2004 16:43, John Goerzen wrote:
One of the most important features of a modern language is, to me,
exceptions. I have found very little coverage of exceptions in Haskell,
what what coverage there was seemed to be centered on I/O.
There's three things one might call
But, being able to see the context in which a thunk was constructed would be
extremely useful.
Yes of course... I was thinking along the lines of what is possible, rather
than what is desirable. If only ghc had a -g (debug) flag like gcc that would
force each funtion to push its entry onto some
Alastair Reid wrote:
3. Can I define my own exception types?
Sadly, no. There is only one 'exception type'.
You can use dynamics and encode new kinds of exceptions as Strings
but that isn't very satisfactory.
But not at all, allowing you to declare your own exception types is
*exactly* what
MR K P SCHUPKE [EMAIL PROTECTED] writes:
As for head, I think it's fine that it throws an error because it is
specified to be defined for only non-empty lists.
But surely it is better to encode this fact in the type system by
useing a separate type for non-empty lists.
Yes, in principle.
Yes, in principle. But that means you still need to write more and
tedious code to deal with it.
Just because code is tedious does not mean it is not necessary to
handle all corner cases. A robust application does not fail when
given unexpected input.
Are you going to discard lists in favor of
mins = map ((\(x:_)-x).sort)
maybe what you meant was:
case sort x of
(x:_) - ... do whatever with x ...
_ - ... do failure conition ...
As I said, if you can _guarantee_ non failure I guess head is okay, but the
fact that this thread started with the observation
On Tue, Aug 03, 2004 at 12:51:50PM +0200, Ketil Malde wrote:
Is there any easy way (TH?) to amend these to output the line number
of the offending caller? It would be a great improvement to see
something like
Prelude.head : empty list in Foo.hs, line 4711
since programs generally
Ketil Malde [EMAIL PROTECTED] writes:
Hmm...if I run it through CPP and
#define HEAD (\x - if null x then error (__FILE__:__LINE__) else head x)
is the __LINE__ resolved at the place of declaration or at the place of usage?
According to the C standard, at the position of /usage/ of the
MR K P SCHUPKE [EMAIL PROTECTED] writes:
mins = map ((\(x:_)-x).sort)
maybe what you meant was:
case sort x of
(x:_) - ... do whatever with x ...
_ - ... do failure conition ...
No, I don't think so. I only want the bug to be reported, and the
umatched pattern
No, I don't think so. I only want the bug to be reported
I think preventing the bug using the type system if possible is a good
idea... something that should be encouraged!
and not a corner case that should be handled.
So if the list depends on user input is not the empty list a corner
case
David Roundy [EMAIL PROTECTED] writes:
Here bug is a function that just calls error with a little prefix
explaining that there is a bug in darcs, and would the user please report
it. Obviously, defining a head here would be just as easy,
Cool! The basic trick is just to inline the actual
Ketil Malde [EMAIL PROTECTED] writes:
Unless I'm overlooking something
Which I of course did.
#define at (let {at (y:_) 0 = y; at (y:ys) n = at ys (n-1); at _ _ = bug at
__FILE__ __LINE__} in \a x - at a x)
No prize for spotting the bug here.
-kzm
--
If I haven't seen further, it is by
Ketil Malde [EMAIL PROTECTED] writes:
import Prelude hiding (head,(!!),read)
Any comments?
Here's one: I thought this would make it difficult to have other
imports of Prelude, hiding other pieces of it (e.g. catch, to avoid
ambiguities with Control.Exception.catch)
(Also, the definition of
Two observations:
1. When I recently modified the HaXml XML parser, this is one of the
significant changes I made: providing (alterantive) return values based on
Either, so that input errors could be handled by the invoking function,
without forcing it into the IO monad. I guess that's a vote
Graham Klyne [EMAIL PROTECTED] writes:
2. I like to distinguish between expected errors and unexpected
errors. Having been burned in the past by using exceptions (not FP),
I try to use them only for conditions that are truly unexpected;
i.e. _exceptional_. Bad input, IMO, is something that
Hi - I am just learning Haskell and am far away from exception handling
intricacies. However I just recently read an article of Herb Sutter
about exception handling in C++ with some rules when to use exception
handling - and perhaps these rules might be applicable to Haskell too
(article: When
W licie z wto, 03-08-2004, godz. 13:05 +0200, Bjoern Knafla napisa:
Herb Sutter gave these rules :
An error is any failure that prevents a function from succeeding. Three
main kind of errors:
[...]
These kinds don't explain much. They don't give a clue which errors
to report by exceptions
Exceptions should only really be used for unpredictcable events, I find
that the defintion of functions like head is lacking rigor... I would
prefer to see:
head :: [a] - Maybe a
head (a0:_) = Just a0
head _ = Nothing
In principle, yes, but in practice, that would be silly. You use
head
f (case xs of (x:_) - x; [] - error whoops) -- direct style
Yup, this is how I do it... I never use head!
I like to pass failures back up to the level where some kind of sensible
error message can be generated. In your example the error is no
better than with 'head' - the point is a Nothing
Prelude.head : empty list
Prelude.read : no parse
andPrelude.(!!) : index too large
and so on.
Is there any easy way (TH?) to amend these to output the line number
of the offending caller?
In a program of any size, I usually avoid using these functions and instead
A lot of programming errors come from failure to correctly validate.
This was actually nicely illustrated in my program: I assumed that digitToInt
accepted '0'..'9' and wanted to rely on it throwing. After puzzling over
out of range errors (other functions expected digitToInt to be in the 0..9
At 15:28 03/08/04 +0100, MR K P SCHUPKE wrote:
f (case xs of (x:_) - x; [] - error whoops) -- direct style
Yup, this is how I do it... I never use head!
As a general principle, this bothers me.
In the longer term (i.e. if and when large-scale production Haskell systems
become common), and as a
MR K P SCHUPKE [EMAIL PROTECTED] writes:
head :: [a] - Maybe a
head (a0:_) = Just a0
head _ = Nothing
Argh, no! Violating the precondition of head is a bug in the caller,
I want it to crash, but I also want to know where. Wrapping it up in
Maybe (or any other error propagation) is not a
On 03-Aug-2004, Evan LaForge [EMAIL PROTECTED] wrote:
In response to the mysterious head exceptions thread, isn't there a way to
compile with profiling and then get the rts to give a traceback on exception?
There is, but it doesn't really work properly, due to
- lazy evaluation
David Menendez writes:
MR K P SCHUPKE writes:
I would suggest using the type system as I said earlier so:
toNonEmptyList :: [a] - Maybe (NonEmpty a)
toNonEmptyList (a0:_) = Just (NonEmpty a)
toNonEmptyList _ = Nothing
Then redefine head:
head :: NonEmpty a - a
head
47 matches
Mail list logo
