Thank you for the programming practice recomendation, but I would still prefer to have something like the implicit parameters solution I described. The solution you describe forces you to put code in functions to handle cases that are outside its domain. Usually I just want to know what function are calling with the pathological input. e.g. quadratic a b c = read $ show ((-b + root)/2/a),(-b - root)/2/a) where root = sqrt(b*b - 4*a*c) I want to know which function is passing in things to make the root imaginary or a==0. I don't want to rewrite this function so it handles these exceptions explicitly. -Alex- _________________________________________________________________ S. Alexander Jacobson mailto:me@alexjacobson.com tel:917-770-6565 http://alexjacobson.com On Wed, 23 Jun 2004, MR K P SCHUPKE wrote:
I like to write programs so functions cannot fail... so head should really be:
maybeHead :: [a] -> Maybe a maybeHead (a:_) = Just a maybeHead _ = Nothing
etc...
The the calling function can do something like:
case maybeHead x of Just y -> <expr y> Nothing -> fail "failed in..."
This way you can pass the failure back up to somewhere where its meaningful.
In my opinion you should either be encoding failure in the return type, or using exceptions... anything else is just bad coding.
Finally use guards (that can be conditionally compiled out) before functions that might fail:
if null x then fail "sesible error message" else ...
Keean.