"Brust, Corwin" wrote:
>
> Peter Scott wrote:
> >
> > I think it would be best to supply a reference. This is a
> > mammoth RFC already and it will be decided on by people who
> > very well know what exception handling is; their reading time
> > is at a premium.
>
> Decided on, yes, but having th
-Original Message-
From: Peter Scott [mailto:[EMAIL PROTECTED]]
or even the cooler
throw Exception::MyDB "ABC.1234" => "Some message about what went
wrong"
O! I like that! I guess I might come to love C after all.
I think it would be best to supply a reference. This
At 11:02 PM 8/17/00 -0600, Tony Olekshy wrote:
> > Note: I used to favor $_[0] for the exception, but I'm being
> > won over to $@. As long as it doesn't cause problems with
> > external interfaces. Might mention the $_[0] idea in a
> > footnote.
>
>Done.
Um, see last message. There's a lot to
Peter Scott wrote:
>
> Tony Olekshy wrote:
> >
> > trap { $@->{message} =~ /divide by 0/ } catch { ... }
>
> I don't think you need another keyword here. Just support an
> expression argument to catch and you can do
>
> catch $@->{message} =~ /divide by 0/ { ... }
>
> If it needs t
At 06:10 AM 8/17/00 -0600, Tony Olekshy wrote:
>catch "Error::DB" { ... }
>
> catch [ "Error::DB", "Error:IO" ] { ... }
>
> trap { $@->{message} =~ /divide by 0/ } catch { ... }
I don't think you need another keyword here. Just support an expression
argument to catch and you can do
On Thu, 17 Aug 2000, Tony Olekshy wrote:
> trace
>
> A listref containing a snapshot of the call-stack as at the time
> the exception is first raised. The array contains hashes (one
> per call stack level), each containing one key value pair for
> each snapshot value at that lev
