Luke Palmer <[EMAIL PROTECTED]> writes: > This is more of a language thang, so I've redirected your message > there [here]. > >> The most fundamental feature throwing an exception is that it transfers >> program execution from the call site. Allowing the caller to resume >> execution at that site is a very dangerous form of action at a distance. > > According to you. :-) > >> I think you'd be better off a giving the caller an explicit way to >> inhibit throwing an exception. That is, use program design rather than >> language features to provide this functionality. e.g., a delegate: >> >> $ex = new My::Exception: ...; >> die $ex >> unless .delegate && .delegate.should_ignore_ex($_, $ex)); >> >> Not only is the above pattern clearer to read and less afflicted by >> action at a distance, but it provides a wider bidirectional interface. > > It also has high inertia and is pretty verbose for error reporting. > The thing about reporting errors is that it needs to be short, easy to > type, easy to think about, or else people won't do it. Everyone did > error checking in Perl 5 because it was a simple little C<or die>. > > But I think you've got one thing right: giving the exception thrower > control. The thing about C<die> is that it denotes a fatal error -- > saying C<die> in a function is basically saying "I can't continue > after this"... so you I<probably> shouldn't be allowed to continue it. > If an error isn't fatal, you're supposed to use C<warn>.
What's being said is "I can't continue after this with the data and code as they are". I can envisage Perl code running in a Smalltalk like environment where catching such an exception would throw up a debugger allowing the programmer to alter either a variable, the exceptional code, or just faking a return value and either retrying or continuing. This kind of approach makes for a remarkably powerful way of doing, say, test first programming. You just write your test and start the test suite running, when this throws an 'unknown method exception' or whatever, you use the debugger to implement/stub out the method in question, retry, and repeat until the test stops throwing exceptions. > So, maybe what's needed is a C<warn> catcher (C<WARNCATCH>... eew), > where C<warn> would throw an exception object with an attached > continuation. And of course, if a warning reached the top of the > stack without being caught, it would print itself and invoke its > continuation. In theory a thrown exception can include everything that's known about the runstate of your program at the time the exception was thrown. And it can't know how that information may be used by some handler up the chain. This implies to me that the correct behaviour when throwing a generic exception is to bundle up all the information available and leave it up to the catcher to decide what to do with it. Yes, this does mean that the catcher might be able to do some Really Stupid things, but if you don't open the door to Mr Stupid you are in danger of slamming it in the face of Mr Powerful. It seems to me that Perl's usual approach in such situations has been to leave the door unlocked... -- Piers
