Consider a case such as this:
$ darcs get darcs get http://darcs.net
darcs failed: You must provide 'get' with either one or two arguments.
This is a non-fault failure -- the program failed, not because of a
bug (fault) in Darcs, but because of a mistake outside of Darcs.
Currently we have impossible.h to handle faults consistently. You can
look for calls to impossible.h's definitions to find all the expected
fault modes.
We don't have anything like this for expected failures modes.
Instead, we just have base/fallback cases like
f [] = putStrLn "You gave darcs wrong arguments."
Would Darcs benefit in code clarity by handing failures consistently,
as we do for faults? At the very least, the help strings printed in
such cases could be vastly improved. In the "darcs get" example
above, get's usage could be printed, and it could tell the user that
he passed three arguments. (The latter is important when calling
darcs from a script, since without tracing, it may not be obvious that
there ARE three arguments in the darcs get call.)
|