[Chicago-talk] Errors. And the reporting thereof.

[Jim Thomason]

> One thing you can do at the #! level is to trap the
> unhandled exceptions so that you have a better idea
> where they happen. This can be implemented in stages
> by $SIG{__DIE__} = sub { ... } to existing pieces of
> code you can trap aptosis in your sub's -- that or
> wrapping the top-level call in a block eval.
> You can then start adding die clauses where undef's
> are assigned to the returns:
> 	$foo = undef;
> becomes
> 	die "Undefined $foo";
> At which point the die handler (or top-level eval)
> can
> deal with reporting the cause of death.
> One way to handle this is:
> 	#!/blah/perl
> 	eval
> 	{
> 		your old code here...
> 	};
> 	die "$0: $@" if $@;
> 	exit 0;
> [useing perl -i to automate this if you like :-].

This still pretty soundly violates condition (1) (the
piece-meal roll out). Even if we do use the itty bitty
commandline doohicky to automate it for us, we're
still changing a massive amount of code, which
wouldn't be good.

Besides, exactly what good does the top level die
handler do for us? Unless there's some slick approach
I'm not considering, we'd end up zooming to the top
handler (the sighandler or the global eval) just about
instantly. And when that happens we choke with a very
generic error.

We can't do that. It's a live, running, web app. Right
now we give the users generic errors, but they're
inline on the screen and they can basically continue
to work. This would be a new error page that they'd
then jump to that doesn't give them anything
additional that's useful, and would probably just
confuse and/or upset them. Not good.

We'd basically need the global handler to catch the
die, note it somewhere, and return back to where we
were, returning an error code in the process. As the
stopgap 'til things would be ported, of course.

> Now go in and either modify the routines that see
> undef
> with something like:

Again, violates condition (1). :) There's an awful lot
of code involved here, and this approach seems to
hinge upon us modifying all of it to catch things,
lest the user get kicked out with the global die
handler implemented up above. 

> If this looks pretty much like textbook exception
> handling,
> you're right.

It does and it is. But exceptions aren't my preferred
approach in general, and not in this case
specifically. First of all, like I said, the system
doesn't use exceptions now. So if we took an
exceptions based approach, we'd have both exceptions
and errorcodes running around at the same time, at
least temporarily, since we're not going to re-write
everything in one swoop to use exceptions instead.

In general, like I said, it's a religious debate. I'm
not a fan of exceptions for a few reasons. First of
all, you can end up hiding the location of the error
from the user. If foo() handles an error, and calls
bar(), which calls baz() which throws the error,
you'll jump out of bar when it blows up and back into
foo() with little indication as to what's going on.
It's confusing.

To alleviate some of the confusion, you can trap the
error a level above and then re-throw it if it's not
something you handle. But at that point, you've
effectively re-implemented an error code based
approach. The only advantage is that you're forced to
handle it at at least one level. I don't see any real
advantage to typing:

eval (
	$obj->foo();
}

if ($@ =~ /exception1/) {
	#handle
elsif ($@ =~ /exception2/) {
	#handle
}
.
.
.

instead of:

unless (defined $obj->foo()) {
	if ($obj->err =~ /exception1/) {
		#handle
	}
	elsif ($obj->err =~ /exception2/) {
		#handle
	}
	.
	.
	.
};

Same thing, just slightly different syntax. The only
real difference is that an errorcode approach forces
you to always bubble up (exceptions can be caught at
higher levels), and the exceptions force you to always
catch it at least once.

But that's all philosophy. If exceptions look like the
best approach to take, we'll consider them.  But I
don't think this'll work w/o lots of code re-working,
which we don't want to do at once.

-Jim....

__________________________________
Do you Yahoo!?
Protect your identity with Yahoo! Mail AddressGuard
http://antispam.yahoo.com/whatsnewfree