Henning Thielemann wrote:
Jonathan Cast wrote:
> Xiao-Yong Jin wrote:
> >
> > Could you elaborate more about why this kind of breakage
> > wouldn't happen if 'try' is used in an IO monad as intended?
>
> It would. But it would happen in IO, which is allowed to be
> non-deterministic. Pure Haskell is not allowed to be non-deterministic.
In my opinion, 'try' catching 'error's is still a hack, since 'error's
aka bottom mean programming error. Thus catching them is debugging, bug
hiding or something worse, but not exception handling. 'try' and friends
should be limited to exceptional outcomes of IO actions, e.g. "disk
full", "file read protected" etc. There might be a variant 'unsafeTry'
which can also block 'error's.
+1.
I have long been disappointed by a number of `error`s which shouldn't
be. For example, the fact that `head` and `div` are not total strikes me
as a (solvable) weakness of type checking, rather than things that
should occur as programmer errors/exceptions at runtime. The use of
`error` in these cases muddies the waters and leads to a laissez-faire
attitude about when it's acceptable to throw one's hands up in despair
and use `error` rather than writing a better function.
As nice as exceptional control flow is, I can't help but think there was
a reason the H98 committee said that `error` should be uncatchable. That
we'd like to be able to catch errors in an interpreter or debugger is
the exception that proves the rule. Extensible exceptions are
impressive, but the existence of exceptions outside of type annotations
says something about purity. Let us not err in the direction of Java,
but we really should plug that hole.
--
Live well,
~wren
_______________________________________________
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe
