Re: what's the deal with user error on fail?
On Thu, Nov 13, 2003 at 09:23:04AM -0800, Iavor S. Diatchki wrote: i would say that if you are wanting to report errors to users, you should not use fail or error. you should instead explicitly report the error. And how does one explicitly report an error? I would normally do it by implementing something functionally equivalent to fail. Why not let fail serve this purpose? but to answer your question, i think the motivation behind user error, is that this is the user from the perspective of the compiler writer, i.e. the programmer. i think one should think of those errors as analogous to segmentation fault in C, or java's unhandled exceptions, i.e. in a well written program the user of the program should never see them, but they can be useful to the programmers while debugging their code. I guess it seems like a better term than user error could be come up with, since most users thing that it means them. Assuming I don't use it for normal errors (the sort that should happen), then the only time they'll see this message is when I have a bug in my code. When that happens I'd much rather have them see something like bug or programmer error so they'll report it, rather than user error, which makes them wonder if they did something wrong. -- David Roundy http://www.abridgegame.org ___ Haskell-Cafe mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: what's the deal with user error on fail?
And how does one explicitly report an error? I would normally do it by implementing something functionally equivalent to fail. Why not let fail serve this purpose? There's several different needs in reporting errors. One is to help with debugging which is what error, pattern match failure, etc. do. A quite different one is to tell users of your application that they have done something wrong (e.g., file they specified doesn't exist, etc.) The standard Haskell functions are primarily targetted at the first usage (we could argue about how well they do it). For text-based applications, I find the following to be a good starting point. -- | -- Print an error message and exit program with a failure code failWith :: Doc - IO a failWith msg = do printDoc PageMode stderr msg exitFailure -- | -- Print an error message and exit program with a failure code abortWith :: Doc - a abortWith msg = unsafePerformIO (failWith (text $$ text Error: + msg)) -- | -- Print message to stderr if condition holds blurt :: Bool - Doc - IO () blurt False msg = return () blurt True msg = printDoc PageMode stderr msg For applications that use a GUI and for situations where the problem is not fatal, you would want different functions again. Hope this helps, -- Alastair Reid www.haskell-consulting.com ___ Haskell-Cafe mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: what's the deal with user error on fail?
hello, i would say that if you are wanting to report errors to users, you should not use fail or error. you should instead explicitly report the error. when i program i typically use error in situations that i think are imposible, but if there is a bug one gets a better error messeage. i don't use fail (well except sometimes implicitly in list comprahensions). the reason i avoid fail is that it seems hackish to me -- it implies that every monad supports errors and this should not be the case. not to mention that often the error that needs to be reported is not a string. but to answer your question, i think the motivation behind user error, is that this is the user from the perspective of the compiler writer, i.e. the programmer. i think one should think of those errors as analogous to segmentation fault in C, or java's unhandled exceptions, i.e. in a well written program the user of the program should never see them, but they can be useful to the programmers while debugging their code. David Roundy wrote: When one triggers an exception with something like fail Error opening file The user gets a message like Fail: user error Reason: Error opening file which is confusing to the user, because it the user's fault. Is there some other way that it is recommended one fail? Or should I be catching userErrors at the top level and failing with my own error message? -- == | Iavor S. Diatchki, Ph.D. student | | Department of Computer Science and Engineering | | School of OGI at OHSU | | http://www.cse.ogi.edu/~diatchki | == ___ Haskell-Cafe mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: what's the deal with user error on fail?
David Roundy [EMAIL PROTECTED] wrote: i would say that if you are wanting to report errors to users, you should not use fail or error. you should instead explicitly report the error. when i program i typically use error in situations that i think are imposible, but if there is a bug one gets a better error messeage. i don't use fail (well except sometimes implicitly in list comprahensions). the reason i avoid fail is that it seems hackish to me -- it implies that every monad supports errors ^^^ In Haskell, this is indeed the case---every monad is after all a monad transformer applied to Haskell's identity monad, which supports errors (hence the existence of Haskell's `error' function :). So even if a monad designer doesn't explicitly add error support, the monad still supports errors. Jon Cast ___ Haskell-Cafe mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: what's the deal with user error on fail?
hello, well that's because haskell is not as pure as it claims to be :-) if every monad supports errors depends on what you mean by supporting errors. i would argue that supporting errors and divergence is not the same thing. the difference is that one should be able to handle an error thrown by a computation, while clearly we cannot detect nonterminating computations. bye iavor Jon Cast wrote: David Roundy [EMAIL PROTECTED] wrote: i would say that if you are wanting to report errors to users, you should not use fail or error. you should instead explicitly report the error. when i program i typically use error in situations that i think are imposible, but if there is a bug one gets a better error messeage. i don't use fail (well except sometimes implicitly in list comprahensions). the reason i avoid fail is that it seems hackish to me -- it implies that every monad supports errors ^^^ In Haskell, this is indeed the case---every monad is after all a monad transformer applied to Haskell's identity monad, which supports errors (hence the existence of Haskell's `error' function :). So even if a monad designer doesn't explicitly add error support, the monad still supports errors. Jon Cast ___ Haskell-Cafe mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/haskell-cafe -- == | Iavor S. Diatchki, Ph.D. student | | Department of Computer Science and Engineering | | School of OGI at OHSU | | http://www.cse.ogi.edu/~diatchki | == ___ Haskell-Cafe mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: what's the deal with user error on fail?
David Roundy [EMAIL PROTECTED] wrote: hello, well that's because haskell is not as pure as it claims to be :-) Nonsense. Haskell is perfectly pure; the IO monad is just nondeterministic :) if every monad supports errors depends on what you mean by supporting errors. I mean `supporting errors' in the only possible sense that `supporting errors' can be implied by the existence of `fail': we have a throw function. i would argue that supporting errors and divergence is not the same thing. I never said it was. the difference is that one should be able to handle an error thrown by a computation, Although this doesn't imply the existence of a `catch' HOF; see the MonadPlus instance for Maybe. while clearly we cannot detect nonterminating computations. Of course. But we can detect exceptions thrown by `error'. Even though we can't distinguish them from non-termination /in pure Haskell/. We can of course distinguish them in the IO monad (which perhaps ought to be re-named the SinBin monad, to be more honest...). So we can detect erroneous computations in any monad. Jon Cast ___ Haskell-Cafe mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/haskell-cafe
