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
