At 01:07 PM 8/29/00 -0600, Tom Christiansen wrote:
> >Now, every error is guaranteed to be an object. You can call some method
> >or check some attribute of it to find out if it was an exception. If
> >you're checking a system() or `` failure, you use it in numerical
> >context. If you're check
>Now, every error is guaranteed to be an object. You can call some method
>or check some attribute of it to find out if it was an exception. If
>you're checking a system() or `` failure, you use it in numerical
>context. If you're checking a builtin failure, you use it in string
>context (u
At 09:41 PM 8/28/00 -0600, Tony Olekshy wrote:
>I just want the cognitive simplicity of knowing that $@ and every
>@@ isa Exception, no matter what.
>
>Why not merge $!, $^E, and $@ into $!, but leave $@ alone too?
>That way, none of the existing die/eval code will break without
>being modified to
Peter Scott wrote:
>
> Tony Olekshy wrote:
> >
> > So if open, for example, can set $! without invoking die, then
> > $! and $@ must not be merged. As I read it, 151 would (as
> > currently promulgated) not meet my requirement for the unique
> > nature of a $@-style variable. I don't think ov
At 01:42 AM 8/25/00 -0600, Tony Olekshy wrote:
>Peter Scott wrote:
> > If $@ and $! are merged, then in code like
> >
> > try {
> > system_call_that_fails();
> > more_stuff_that_succeeds();
> > }
> > finally {
> > }
> >
> > does
At 10:13 AM 8/25/00 +0200, Bart Lateur wrote:
>You're citing my objection for merging in $@ with the rest of the error
>variables. $@ currently is the "eval failed" flag, irrespective of what
>else failed. We *must* have such a flag. If $@ and $! would be merged,
>$! will have to be cleared if the
Peter Scott wrote:
>
> Tony Olekshy wrote:
> >
> > In fact, not only would I be pleased and honoured to author the
> > Perl 6 core Try.pm module, I'm already working on a Perl 5 standard
> > reference implementation.
>
> > Peter, I think we should make this approach more clear in RFC 88.
>
> I'
On Thu, 24 Aug 2000 17:57:55 -0700, Peter Scott wrote:
>>I've read 151 a few times, and I don't understand how it can impact
>>the implementation of RFC 88 as a module. Please explain.
>
>If $@ and $! are merged, then in code like
>
> try {
> system_call_that_fails();
>
Peter Scott wrote:
>
> At 06:48 PM 8/24/00 -0600, Tony Olekshy wrote:
> >
> >I've read 151 a few times, and I don't understand how it can
> >impact the implementation of RFC 88 as a module. Please explain.
>
> If $@ and $! are merged, then in code like
>
> try {
> sys
At 06:48 PM 8/24/00 -0600, Tony Olekshy wrote:
>Peter Scott wrote:
> >
> > At 06:06 PM 8/24/00 -0600, Tony Olekshy wrote:
> > >
> > >In fact, not only would I be pleased and honoured to author the
> > >Perl 6 core Try.pm module, I'm already working on a Perl 5 standard
> > >reference implementatio
Peter Scott wrote:
>
> At 06:06 PM 8/24/00 -0600, Tony Olekshy wrote:
> >
> >In fact, not only would I be pleased and honoured to author the
> >Perl 6 core Try.pm module, I'm already working on a Perl 5 standard
> >reference implementation.
>
> >Peter, I think we should make this approach more c
At 06:06 PM 8/24/00 -0600, Tony Olekshy wrote:
>In fact, not only would I be pleased and honoured to author the
>Perl 6 core Try.pm module, I'm already working on a Perl 5 standard
>reference implementation.
That should certainly tell you whether it's doable :-)
>Peter, I think we should make th
Graham Barr wrote:
> Peter Scott wrote:
> > Tony Olekshy wrote:
> > > Graham Barr wrote:
> > > >
> > > > I am of the opinion that only a class name should follow
> > > > catch. If someone wants to catch based on an expression
> > > > they should use
> > > >
> > > > catch {
> > > > if () {
>
13 matches
Mail list logo
