On 22/09/2010 09:51, Mitar wrote:
Hi!
On Wed, Sep 22, 2010 at 10:21 AM, Simon Marlow<marlo...@gmail.com> wrote:
You could use maskUninterruptible, but that's not a good solution either - if
an
operation during cleanup really does block, you'd like to be able to Control-C
your
way out.
So maybe this shows a need for maskUninterruptibleExcept (user
exception for example).
So the only way out of this hole is: don't write long cleanup code that
needs to mask exceptions. Find another way to do it.
There is sometimes no other way. For example if cleanup requires
extensive IO with robot on the Mars. It takes time for communicating
in each direction and while waiting for the response it is really not
a great idea that robot on the Mars is left in undefined state because
cleanup function has been interrupted half a way doing its thing. Of
course the protocol would be probably just that you send a message
like "I am going away for some time, please confirm" and you wait for
confirmation. So in most cases it will be OK even if the you do not
really wait for confirmation, but sometimes there will be no
confirmation and you will have to retry or try something else (like
raise an alarm). (The point of such protocol message is that robot
does not consume power trying to reach you when you are not there.)
Instead of thinking of this as "cleanup code" that runs in an exception
handler, rather the program that communicates with the rover would have
a state in which it is "recovering". The exception handler moves the
program into the recovery state, and then continues. During the
recovery state you can mask exceptions if you like, but you can also
catch exceptions and handle them as you would in any other state.
The point I'm making here is that when cleanup code gets long and
unweildy, it should become part of the main program logic rather than an
exception handler.
But yes, in this case I will simply use maskUninterruptible and also
user should be blocked/masked from interrupting the cleanup. (He/she
still has kill signal if this is really really what he/she wants.)
Haskell great type checking is a great tool and help in mission
critical programs, there is just this hidden side effect (exceptions)
possibility built-in in language which has yet to be polished. In my
opinion.
This could be mitigated with "resume" from exception.
exceptions with resumption aren't exceptions, they're signals. We can
already do this in Haskell: you install a handler for the signal, and in
the handler you decide whether to throw an exception to a thread or not.
But this is only one part of the story I am trying to rise here. The
other is that me, as an user of some library function, do not know and
cannot know (yet) which exceptions this function can throw at me. I
believe this is a major drawback.
You're talking about synchronous exceptions, which are a different beast
entirely. Wars have been waged about whether synchronous exceptions
should show up in the types; IMO the Java folks lost here, and the
general feeling is that the Java way was a poor choice (but it was hard
to tell from the outset, they did it for the right reasons).
Maybe what
I am arguing for is that currently (with mask) you cannot say "mask
everything except".
Perhaps, although that's quite tricky to implement. Presumably you
would have to supply a predicate (as a Haskell function), and the RTS
would have to apply your predicate to the exception in order to decide
whether to mask it or not. What if the predicate loops, or raises an
exception itself?
Cheers,
Simon
To answer Bas: I do not know how this should look like. I just know
that I am missing Java's transparency what can be thrown and what not
and its at-compile-time checking if you have covered all
possibilities.
Mitar
P.S.: I am not really doing a remote control for Mars robot in
Haskell, but it is not so much far off. Maybe it will even be there
someday.
_______________________________________________
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe
