On 1/12/11 11:56 AM, Don Clugston wrote:
On 12 January 2011 16:01, Sean Kelly<[email protected]> wrote:
Two errors could still cause confusion though.
Yeah. Though how much of a problem is it?
Catching an Error is a nasty action. A nothrow function is permitted
to throw an Error because it is non-recoverable, so catching it in
order to recover is somehow a bit shady. (Should it be legal to catch
an Error in a @safe function?)
I think @safe means memory-safe so probably it could. Catching Error
means you continue with broken assumptions about the program, but the
memory safety guarantees are preserved.
This whole exception chaining idea is based on the premise that it's
the first error which is the important one. I do think that applies
even to Errors; I think it's still better than C++'s replacement
strategy. Can you think of any other way of doing it?
I agree Error is an out-of-band signal that trumps over the nice chain.
We could say something like, "catching an Error is not something which
should be done lightly. In the rare cases where it is necessary, you
should _always_ check for secondary Errors which may have occurred
while processing the first one."
I'd even be okay with throwing an Error replaces the whole chain. Error
is a worst-case scenario in which you're allowed to lose state and
reduce guarantees.
Andrei
_______________________________________________
phobos mailing list
[email protected]
http://lists.puremagic.com/mailman/listinfo/phobos
