in reply to In time for Wimbledon

The whole point of raising an exception is saying "I can't deal with it, dude", so if you bounce back, well, it still can't handle it. What if a subroutine is designed to throw an exception when a DB connection cannot be established, and then the stupid user bounces the exception back? you'll get a worse condition.

If you just want to change policy of what is fatal and what isn't, just pass an argument saying so.

or, alternatively, use ACME::comefrom to put all your checking in one place... :-)

Replies are listed 'Best First'.
Re: Re: In time for Wimbledon
by dash2 (Hermit) on Jul 01, 2003 at 22:00 UTC
    Yes, this is why I distinguished between lob and throw, and said:

    The idea is that sometimes you definitely want to throw an error - there's no way to continue. On the other hand, you might just want to lob an error back to the caller, and let them decide if they want to go on.

    In other words, if the subroutine throws an exception, you can't bounce it back. But if it lobs one, you can. Obviously, letting user code ignore serious errors would be foolish.

    You could do it by argument-passing, just as you can do exception throwing by returning undef and letting the caller decide whether to die. But that doesn't mean exception-throwing isn't better. The advantage of this is that different calling code can decide to bounce different classes of exceptions. Just like try ... catch, it gives you more fine-grained control.
    A massive flamewar beneath your chosen depth has not been shown here

[reply]
[d/l]
[select]

In Section Meditations