On Fri, Aug 04, 2000 at 09:10:38AM +0200, Johan Vromans wrote:
> You missed the point.
>
> If you need 6+ lines of code for each elementary error check, this is
> what is going to happen . . .
You're correct, but that's not what I was suggesting. The magic words are
`for each elementary error check.' Many (most?) functions do fine with
a simple error codes returned. But there are some cases where things
go wrong deep inside modules and it's not easy/reasonable/feasible to
return anything meaningful in the error code. For circumstances like
that, a try/catch mechanism is wonderful. It's superior to if (eval)
in expressiveness and flexibility as well.
Those who write all their code like this with try/catch (as Johan
suggested):
> try {
> open file
> while read a record
> process its contents
> finalize file processing
> }
> catch (Exception e) {
> error message: something went wrong
> }
are also probably writing their (pseudo-perl) code like
if ( ! ( $err = open file ) ) {
error message: something went wrong
} else while ( $err = read a line ) {
if ( $err ) {
error message: something went wrong
} else {
process it's contents
}
if ( ! $err ) {
finalize file processing
}
}
Bad code and (in this case) feature abuse are independent of features.
I for one would like a try/catch for the tough cases that need it.
If people want to screw themselves over with abusing it for trivial uses,
that's fine.
PROPOSAL: we should add try/catch to perl, with the caveat that uncaught
exceptions are ignored and an error code returned as per current
functioning.
Or Fri, Aug 04, 2000 at 05:09:13AM -0600, Tom Christiansen wrote:
> >> If you do it the C++ way, you can say:
> >> try {
> >> first_sub_that_throws_exceptions();
> >> second_sub_that_throws_exceptions();
> >> } catch {
> >> it went wrong
> >> }
>
> >How does 'it went wrong' know _which_ of the subs went wrong?
> ....
As was pointed out elsewhere, the object provided to the catch has
that data. But that's a not really relevant to the clarity, obscurity,
or brevity of code using try/catch. The following working perl code
has recently been removed from some of our tools:
die "Couldn't open database\n" if (!$dhb = open_db("bdconfig", get_dbms("Oracle",
get_host_addr("woody"))));
This statement appeared in the code twice, widely separated, with
different db/dbms/host but the same error message. Needless to say,
it leaves you pretty clueless as to what went wrong. I've directed
our programmers here that such statements should be rewritten to
my $dbh;
my $host = "woody";
my $dbms = "Oracle";
my $db = "bdconfig";
my $why = "why you want it";
my $addr;
if ( ! $addr = get_host_addr( $host ) ) {
die "Couldn't find host '$host' for $why.\n";
} elsif ( ! $dbms = get_dbms( $dbms, $addr ) ) {
die "Couldn't access DBMS '$dbms' on $host for $why.\n";
} elsif ( ! $dbh = open_db( $db ) ) {
die "Couldn't access $dbms db '$db' on $host for $why.\n";
}
or encapsulated in a function which returns an appropriately
informational error string:
if ( "" ne ( $errstr = opendb( "bdconfig", "woody", "Oracle", \$dbh ) ) ) {
print STDERR $errstr;
}
Both the large code block in the first and the implementation of opendb
(not shown) are pedantic as all hell, but now when the NOC pages me at
3AM, I know where to start looking. I submit that both the above call
to opendb with a string error code and the try/catch version:
try {
$db_handle = opendb "bdconfig", "woody", "Oracle" ;
} catch {
it went wrong
}
are about equally readable, and the try/catch is ultimately more powerful.
Jeez, don't tell me I've just started writing another RFC.... smiley/2.
--
``Just imagine we are meeting the aliens for the first time. Most
people would just shoot them to see how many points they are worth.''
Simon Cozens in msg <[EMAIL PROTECTED]>
