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
12 matches
Mail list logo
