what's the deal with "user error" on fail?
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? -- David Roundy http://www.abridgegame.org/darcs
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 | ==================================================
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
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
participants (3)
-
Alastair Reid -
David Roundy -
Iavor S. Diatchki