Markus Peter wrote:
> --On 22.08.2000 12:24 Uhr -0400 Chaim Frenkel wrote:
>
> > TO> return $FATAL_MODE ? ERROR_IO : throw Error::IO;
> >
> > Why make all module authors do that? Have core perl do that for you.
> > Make a pragma that would treat throw as a return. No cost to the
> > module author.
>
> This probably won't work. What would you return exactly? Also, there's
> plenty of chance that the return value could interfer with the regular
> return values of that function... This will never be possible without work
> done by the module author so the return value plays nicely.
There is a matter of style of programming. When people write simple
expressions
$a = $b + $c;
(no ties in this example) it is pretty obvious that few errors are possible,
and maybe none that need to be checked. When people write complex expressions
non-OO:
$a = & foo ( $b, & bar ( $c ));
OO:
$a = $b -> method1 ( $c -> method2 ( $d ));
then it would appear that they are not robustly checking for errors. Now it is
possible that & bar and method2 would never return errors, I don't know what
they do. But if there is a possibility that they might, it would seem that
either the error is unchecked, or &foo and method1 must be robust enough to
deal with the results produced in the presence of an error, and, not knowing
what they do either, perhaps that may be the case.
However, let's look at what it takes to check the errors, should they occur,
and should &foo and method1 not be robust enough to handle them...
Without exception handling:
non-OO:
$temp = & bar ( $c );
if ( ERROREXPR1 ) { ... };
$a = & foo ( $b, $temp );
if ( ERROREXPR2 ) { ... };
OO:
$temp = $c -> method2 ( $d ));
if ( ERROREXPR3 ) { ... };
$a = $b -> method1 ( $temp );
if ( ERROREXPR4 ) { ... };
With exception handling (RFC 119 style):
non-OO:
$a = & foo ( $b, & bar ( $c ));
catch ( ERROREXPR5 ) { ... };
catch ( ERROREXPR6 ) { ... };
OO:
$a = $b -> method1 ( $c -> method2 ( $d ));
catch ( ERROREXPR7 ) { ... };
catch ( ERROREXPR8 ) { ... };
Now ERROREXPR1 & 3 might do something along the lines of "! defined $temp" for
functions that might use an undefined return value as an error indicator. Per
RFC 119, ERROREXPR5-7 would all be written in terms of @_, which is where the
values thrown are available.
If all errors are to be treated fatally, we can, with exception handling,
simply omit the catch phrases (returning to the original example). However,
without exception handling, if a function returns funny values when it fails,
we must either check for them and die, or not check for them, and get funny
results as a result of using the funny values returned, or expect the function
to die internally for all errors (which limits the generality of the function
for code that wishes to handle the errors).
Hence, exception handling (with or without catch phrases) allows the normal,
non-error case to be coded more simply both when you don't care about catching
errors (die), and when you do.
Some discussion has been made about ignoring errors from certain parts of the
code. This is the only item that gets more complex with exception handling--
they must be ignored explicitly, as in (RFC 119 syntax again):
{ & ignore_my_errors ( @params ); catch {}};
This intrudes only slightly on code that is handling all the rest of the errors
anyway, and just wants to ignore them here.
> I'm not so sure either wether a function should only return error codes
> when it's called in non-fatal mode. I'd actually prefer to be able to
> enable/disable fatality for exceptions with a pragma without changing the
> interface (though that doesn't prevent having a mode where we'll have error
> modes), so that I can check exceptions when I want to....
"enabling/disabling fatality for exceptions with a pragma"... if the idea is
that control continues linearly past a throw, then sub/module authors must
write twice the error handling logic, which is painful. If it means that the
destination of the throw is bounded to some boundary, that boundary must be
defined... so I guess that's a scoped pragma, so the syntax would be something
like
{ use no_fatal_throws;
& ignore_my_errors ( @params );
}
That's just about exactly the same length and complexity as the null catch
phrase above, which does exactly the same job.
--
Glenn
=====
There are two kinds of people, those
who finish what they start, and so
on... -- Robert Byrne
_____NetZero Free Internet Access and Email______
http://www.netzero.net/download/index.html
