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.) 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. 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. Code behavior should be transparent and types do help here. But (possibility of) exceptions are hidden. To be prepared for any exception (even those not yet defined at the time of writing) in code is sometimes a too hard requirement (you are writing about async-exception-saftiness). Especially because for some exceptions you could want some behavior and for some other. Maybe what I am arguing for is that currently (with mask) you cannot say "mask everything except". 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
