On Mon, 30 Apr 2001, Matt Sergeant wrote:
> On Mon, 30 Apr 2001, Jeffrey W. Baker wrote:
>
> > Yes precisely. It used to be that you could only die() with a string, but
> > 5.<mumble> gave us die() with a reference to an object and at that moment
> > the system was complete. The creation of a rational exception object type
> > is left to the discretion of the system designer (thankfully).
>
> Well actually I personally would prefer proper exception semantics, but
> unless someone re-writes Error.pm (or whatever) to be implemented using
> Filter, then we're stuck with closures, which I'll avoid thank you.
>
> The things I don't like are:
>
> You currently have to do two blocks, one if ($@), and then
> if($@->isa(...)) inside that. That's too much typing, when Perl is so
> renouned for it's succinctness (is that a word?).
>
> The second thing is no finalize/always clause (you can sort of emulate it,
> but it's not quite guaranteed like it is in languages that implement it
> properly - we discussed this yonks ago on perl-friends, I'll try and dig
> up the discussion if you want).
>
> The whole $@->isa() thing, it's just plain ugly, and doesn't really look
> like exception handling - it looks like botched up OO code. It can/should
> be more structured IMHO.
>
> It's also another case of far too many ways to do it, causing people's
> perl code to look different everywhere, which is bad for maintainence.
Well, the nice thing about the way Perl does it is that you can have your
way, and boy am I glad I don't have to do it that way, too.
I have learned that errors from down in the call stack are very rarely
conditionally recoverable. If I call obj->method(), and it throws an
exception, there are few situations where the cause of the exception
matters at all. In most cases I will just not handle the exception, and
it will bubble up. In some cases I might want to log. In others I might
want to retry, or try plan B. But, very rarely do I want to branch on the
type of exception. Right now I cannot in fact think of any program I have
written that branches on the type of exception. Java encourages this with
multiple catch blocks, but I think it is stupid and anyway the catcher
usually is not the primary source of knowledge about what the hell
happened. Think of it: the called program had to make a decision about
what exception to throw, and now the caller is trying to decode that
exception. I believe that decisions should be made at the place in the
program that has the most relevant information about the decision. If you
try to encode information into the exception object, you are encouraging
some other part of the program to make a less-informed opinion.
My coding style dictates that a function or method will always do
everything in its power to succeed. If it returns an error code or throws
an exception, that means permanent failure as far as that function is
concerned. In my C code, I usually find that I only need two values for
my return value: FAILURE and SUCCESS. I rarely need anything beyond that.
The explicit exception declarations in Java piss me off, because they
cause maintenance headaches. Say you have a twenty level call stack. At
depth 0, you catch Exception, at depth 5, you catch FooException. Let's
say that a package API changes and depth 15 now need to throw
BarException. At some level, you now have to explicitly handle
BarException. You either have to do it at depth 14, or you have to change
the declaration of every method up the call stack to the depth that *does*
handle BarException. This is more work than it needs to be.
Regards,
jwb
