High-level technique for program options handling
jyp_7 at yahoo.com
Tue Jan 20 05:46:56 EST 2004
> > I have a question about error reporting. You use
> 'error' quite often. I
> > think that this can cause errors to pop up at
> strange moments during
> > program evaluation. It this a real problem? I
> prefer reporting errors
> > early in the IO monad. I think there is some
> trade-off involved, but I
> > can't name it now.
> You're right, it can lead to late error messages.
> For example, if two output
> files are specified then the program might read its
> input, spend some time
> processing and only report an error after some
> considerable time has passed.
> (I haven't actually seen this happen but I'm sure it
> One reason for using error in functions like
> 'uniqueNoDefault' (which checks
> that a list has precisely one element and either
> returns it or prints a
> useful error message) is that I use this function
> both from the IO monad and
> from pure code. I'm reluctant to duplicate the code
> just to avoid this.
> But maybe I should put it in a monad anyway (and go
> back and 'fix' all
> non-monadic uses)? The error messages produced are
> basically telling the
> user that they made a mistake so I must have just
> read some input from a
> file, the command line or the console.
I'm not certain this applies, but it should be
to force evaluation order with a technique similar to
deepSeq. It might be cleaner than using IO.
Do you Yahoo!?
Yahoo! Hotjobs: Enter the "Signing Bonus" Sweepstakes
More information about the Haskell