> it never got noisy. stick around. i will be posting my set of related
> RFC's. my goal is one a day. i almost have safe signal done. then
> mailboxes, callbacks, event loops, etc. i expect around 8 or so when
> done. any help is appreciated. i am basically taking the async I/O RFC-47
> and chopping it up and expanding each piece to its own RFC.
Well, here's some fuel for the discussion. I've done a fairly large
project (100k lines of code) with perl/mod_perl/Apache and used the
eval/die approach extensivly. It worked out very nicely, allowed us
to capture a large amount of information. Moving $@ to an exception
object that used caller() to detect where it was being thrown added alot
of automation to the process -- capturing the file name and the line number
being the most basic (but in some ways most valueable) data captured.
I'm a big proponent of catching as many errors/problems with my code
at compile time as possible. I don't like deferring things to runtime if
it can be helped.
As an aside, one of the things that I wished was different [better] is method
calls on objects -- if you have a typo in the method name, or you call
a method that's not implemented, you get a run-time error [exception]. It
would have been nice to be able to catch that at compile time (we almost
always used 'perl -wcT' to make sure things compiled). I know this raises
issues with AUTOLOAD and runtime-defined behavior, but some compromise
would have been nice -- perhaps a harder to satisfy compile switch? Hrm,
going that route, a smattering of typing (int/Dog/Foo/etc.) included with
the 'hard' compile switch would help catch problems...
Anyway, back to exceptions:
Fall through was an issue with the eval/if($@) method -- at least when
compared to other languages I've used exceptions in (C++/Java). In those
languages, if you have a try block, you need to have a catch [at least one].
The implementaions of exception handling in Perl that I was able to find
used try/catch in place of the eval/if($@) syntax -- they all had issues
with fall through, as the catch wasn't required. Setting up for exception
handling in one spot in my code, missing the actual type of the exception,
and catching it unexpectadly in another part of the code made things
confusing.
try {
throw(new Bar::Exception('error'));
}
catch( Foo::Exception e ) {
die 'Caught Exception: ',e,"\n";
} # oops, missed Bar::Exception
... # code after uncaught exception continues to be executed
try {
# nothing special
}
catch( Exception e ) {
die 'Caught somebody else's exception',"\n";
}
I would think that a stricter implementation of exception handling would
be desierable. Re-throwing a caught base exception even being acceptable,
even as the default behavior.
try {
throw(new Bar::Exception('error'));
}
catch( Exeption e ) {
rethrow(e);
}
Leaving this up to the discipline of the programmer is a less than
optimum solution IMO, because they'll forget to do it. I know I did
when using OO style exceptions.
Any other thoughts?
Kyle R. Burton
--
------------------------------------------------------------------------------
"A rock pile ceases to be a rock pile the moment a single man contemplates it,
bearing within him the image of a cathedral."
-- Antoine de Saint-Exupery
[EMAIL PROTECTED] http://www.voicenet.com/~mortis
------------------------------------------------------------------------------
