On Sun, Feb 19, 2012 at 11:58:19PM +0100, deadalnix wrote: [...] > I would add that, by thinking at your proposal of exception that may > succed if you retry the same thing, phobos should propose a retry > function that take as parameter a closure and and limit and will retry > the operation until it succeed or that the limit is reached. > > The more I think of it, the more it make sense to have a property on > Exceptions to explicit if a retry may help.
This is starting more and more to sound like what's described in the link that bearophile posted elsewhere in this discussion: http://www.gigamonkeys.com/book/beyond-exception-handling-conditions-and-restarts.html I stand by my objection that if something might succeed if it can be retried, then it needs to be retried in the called function, not the caller. I've already posted a summary of the above link, but I'd like to repeat some of the salient points: - With the current try/catch mechanism, we are limited to two modes of recovery: (1) don't bother, just abort; (2) restart the operation from scratch, and hope it won't fail this time. - To have more intelligent error recovery requires that such recovery take place *in the scope of the function that throws the exception*. - However, the code that throws the exception is usually low-level, and as such does not have the global, high-level context to decide which course of action to take. - By the time a thrown exception gets to said high-level code, the stack is already unwound, the original execution context is long gone, and the only recovery left is to restart the entire operation from scratch. Perhaps the "ideal exception handling facility" that Andrei is looking for is a Lispian model, where: - The low-level function that throws the exception also indicates a list of possible recovery strategies; - The high-level code that eventually calls the low-level function registers exception recovery policies with the runtime (in the form of delegates that choose between recovery strategies or prompts the runtime to unwind the stack); - When an exception is thrown, the runtime matches the thrown exception with the recovery policy, and corrects the problem based on the decision of said policy *in the execution context of the low-level function where the problem occurred*. The stack is only unwound if no recovery policy is available to correct the problem, or if the policy says to abort the operation. Note that the registration of recovery delegates needs to be out-of-band (not passed as function parameters) because there can potentially be a very long chain of calls before the low-level code is reached. Manually propagating lists of recovery delegates through the entire call chain is not practical. It also adds lots of noise to the code (clutters normal code with exception-related code) and adds unnecessary CPU overhead for the usual case when no problems happen. That's why this needs to be done by the runtime system. You also want language support for this mechanism, otherwise you end up with tons of boilerplate code. T -- It only takes one twig to burn down a forest. It only takes one twit to burn down a project.
