At 07:07 AM 8/12/00 -0600, Tony Olekshy wrote:
>One problem I still see with RFC 63 is that there is no syntax for
>doing a string match on the exception's stringification, as in the
>RFC 88 syntax:
>
> except "division by 0" => catch { }
> except qr/div.* by 0/ => catch { }
That's a feature :-) Selecting exceptions by regex matching on the text
attribute is a bad idea, IMHO. What if the message changes in the next
release? What if we one day figure out i18n and the message is in
French? Note the commonality of RFCs 80 and 85, suggesting that error
messages be identified by fixed, unambiguous identifiers.
However, RFC 63 could still do it with
catch {
my $err = shift;
switch ($err->message) {
case /division by 0/ : { }
> > A C<try> block without any C<catch> blocks would be pointless,
> > since uncaught exceptions (i.e., all of them) would be rethrown.
>
>Whoa. What about making sure that if a file is opened then it
>is closed, even if the processing between open and close throws,
>as in:
>
> open(*F, ">foo") or throw ...;
>
> try { ... }
>
> finally { close F or throw ...; }
Ah, thanks. Hadn't thought about using a finally block there.
>It's a pleasure to work with you on these matters.
Ditto.
> It appears
>to me that Peter's approach in RFCs 63 and 80 represents the
>perspective that the exception is the key and handling is just
>what you do with it, whereas my approach in RFCs 88 and 96 is
>that handling exceptions is the key, and the exceptions are just
>what you happen to be handling.
I think it's important to remember that we're just coming up with ideas
here for the people who make the design decisions on P6 to chew over, not
coming to final decisions ourselves. So I view multiple overlapping RFCs
as a good thing; they indicate that there is a common need, that there are
differing sub-needs, and leave open the possibility for a greater genius to
find a solution that makes everyone happy.
--
Peter Scott
Pacific Systems Design Technologies
