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 princi
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 :: NonEmpt
On 03-Aug-2004, Alastair Reid <[EMAIL PROTECTED]> wrote:
>
> Another approach is to use a function:
>
> inContext :: String -> a -> a
>
> (implemented using mapException) like this:
>
> inContext "evaluating expression" (eval env e)
>
> to transform an exception of the form:
>
>error
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
>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.
>Argh, no! Violating the precondition of head is a bug in the cal
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
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 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
>> Is there any easy way (TH?) to amend these to output the line number
Or use GHC's reifyLocation 'function' in a mapException.
Keean.
___
Haskell-Cafe mailing list
[EMAIL PROTECTED]
http://www.haskell.org/mailman/listinfo/haskell-cafe
>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
>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 Nothin
> 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 u
>Sometimes the qualification of an error changes while it is propagated.
There was a discussion about this recently (on the ghc list I think)(
The proposed (partial) solution is to use mapException:
mapExceptionIO :: (Exception -> Exception) -> IO a -> IO a
mapExceptionIO f io = Exception.catch
W liście 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 except
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
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 someth
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
A lot of programming errors come from failure to correctly validate.
I remember being taught to validate on input _and_ validate when
you use a value. So I would say do both - use maybe for input
functions, and exceptions for when you use a value. You can use
the type system to make this more effic
18 matches
Mail list logo
