Yes, that was in there before and was a casualty of bad editing. Thanks
for catching it.
>Finally, I'd vote for $! 1000 times over $@; I've always hated $@
>because of its direct conflict with sh's $@, which is a completely
>different beast altogether.
Ditto.
--
Peter Scott
Pacific Systems Design Technologies
perl.org/msg03111.html that we
could do better than checking integers:
>I think I agree with the folks that say errors should be caught by
>type, not by number. Just as a for instance, you ought to able to
>write a simple handler that catches any ERRNO-style error.
or whether I misunderstand.
--
Peter Scott
Pacific Systems Design Technologies
x27;re checking a builtin failure, you use it in string
context (unless you have some fetish about errno).
I don't know about you, but this sounds pretty good to me.
--
Peter Scott
Pacific Systems Design Technologies
into the -internals part of it. Although if
you were, I'd say that where pp.c does
DIE(aTHX_ "Illegal division by zero");
the DIE will be turned into something that checks fatalism first.
--
Peter Scott
Pacific Systems Design Technologies
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();
&g
will have to be cleared if the eval doesn't fail, just like $@ is
>now.
Yes. Basically, you can think of the new $! as getting done to it whatever
was last done to any of the set of $@, $!, $^E, and $? in the current Perl.
Well, I doubt it will be that simple :-)
--
Peter Scott
Pacific Systems Design Technologies
then the requested category could also be posted
> into a testable variable, allowing module authors who wished to
> to automatically support this functionality as well.
Got anything in mind? $^something?
--
Peter Scott
Pacific Systems Design Technologies
wouldn't you want to just get rid of the whole construct? Is there any
need for it?
--
Peter Scott
Pacific Systems Design Technologies
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 alre
I think we should make this approach more clear in RFC 88.
I'm not convinced that this can totally be implemented in a
module. Particularly if RFC 151 passes :-)
--
Peter Scott
Pacific Systems Design Technologies
>"maybe" die.
There are no existing fatal exceptions. You can call die as much as you
want, but if your caller has wrapped you in an eval block, tough. RFC 88
does not change this at all.
--
Peter Scott
Pacific Systems Design Technologies
work
Um, granted, but if you're going to need additional syntax around your EXPR
to disambiguate it then => seems as good as any and it has that neat "this
thing causes this thing" interpretation.
--
Peter Scott
Pacific Systems Design Technologies
y that would
require another keyword to handle the EXPR case and it didn't seem worth it.
--
Peter Scott
Pacific Systems Design Technologies
l be calls that mean that parts of the interface can no longer be
called, but other parts can, and they'll have to document that too...
--
Peter Scott
Pacific Systems Design Technologies
chival purposes only. Anyone
interested in browsing this for historical reasons probably has way
too much time on their hands :-)
--
Peter Scott
Pacific Systems Design Technologies
precludes die and throw from sharing the same
>underlying
>code, or similarly catch/eval, doing so isn't a good idea: it forces
>people that
>want to use exceptions for non-fatal error handling to suddenly have to also
>handle fatal errors as well.
I think I've already stat
At 04:38 PM 8/22/00 -0600, Tony Olekshy wrote:
>Peter Scott wrote:
> >
> > I thought the discussion was around how
> >
> > throw object;
> >
> > could be a run-time error if object ! isa Exception (which is
> > what I think should happen) i
But that *is* being orthogonal. That's how Error.pm implemented it and it
makes perfect sense. Nothing in RFC 88 precludes die and throw from
sharing the same underlying code, or simlarly catch/eval. I think it
should make it clear that they *are* the same thing.
--
Peter Scott
Pacific Systems Design Technologies
At 08:36 AM 8/23/00 -0600, Tony Olekshy wrote:
>Jarkko Hietaniemi wrote:
> >
> > On Tue, Aug 22, 2000 at 11:07:44PM -0700, Peter Scott wrote:
> > >
> > > I think this should be perl6-language-errors
> >
> > I scoured the -errors but all I coul
w $@ can,
>invoked now as an instance method rather than a constructor,
>do the right thing.
>
>However, a bare C doesn't make sense now, because it's a method.
Like I said before, don't let that stop you if you want to make it do
something; you can just make thr
I know that I do not want RFC 88 to
change its mind. We'll find out what Larry wants in due course. Maybe
neither of the above.
--
Peter Scott
Pacific Systems Design Technologies
s
of that code who want to reserve the right to apply a different
interpretation, which is what Tony was talking about above.
--
Peter Scott
Pacific Systems Design Technologies
tch; I think they
should be synonymous for interoperation (so users aren't forced to migrate
an entire application from one method to the other just because one module
uses the other method). This means that die can be trapped by catch, and
that throw can be trapped by eval.
--
Peter Scott
Pacific Systems Design Technologies
and the framer's
intentions; I'm just putting out an idea.
If we were prepared to mandate that all system calls should return a value
indicating success or failure *and nothing else*, I would probably not
object to RFC 140 as is, but I think that would be unnecessarily crippling
on the language.
--
Peter Scott
Pacific Systems Design Technologies
foo;
>} catch ...; # handle exception
>
>bar;
>...
>bar;
># exceptions automatically ignored again
I'm not crazy about the implicit use fatal. Particularly since there will
be nuances and all-or-nothing may not make sense.
--
Peter Scott
Pacific Systems Design Technologies
the shared scope elimination was a side
effect of another change. No-one has suggested that it is a bad thing per se.
--
Peter Scott
Pacific Systems Design Technologies
ot a function.
throw is a constructor right now, but we don't need to stop us from
suggesting it do something that constructors can't if there's a good case
for it. However, I don't see a good enough case for an argument-less
try. If there were one, it would be that it wa
>block...
>
>So that was:
>
> Any exception raised in a try will be fatal unless caught?
It already is (RFC 88).
--
Peter Scott
Pacific Systems Design Technologies
At 12:43 AM 8/20/00 -0600, Tony Olekshy wrote:
>Peter Scott wrote:
> >
> > At 08:43 PM 8/19/00 -0600, Tony Olekshy wrote:
> > >Peter Scott wrote:
> > > >
> > > > Dave Rolsky wrote:
> > > > >
> > > > > Tony Olekshy wr
At 02:29 PM 8/22/00 -0600, Tony Olekshy wrote:
>Peter Scott wrote:
> >
> > But surely you have to be consistent. I understood Chaim's point to be
> > that he wanted no exceptions if he didn't ask for them. If the core
> > currently dies where it coul
here any exception that's not Ced is actualy a (runtime) error.
I find myself indifferent on the subject of where the exception stack is
stored (well, at least indifferent to the choices of @_ and @@), even given
the ramifications of each. I would like to see each mentioned as
alternatives; I don't mind which one is preferred.
--
Peter Scott
Pacific Systems Design Technologies
At 02:00 PM 8/22/00 -0600, Tony Olekshy wrote:
>Peter Scott wrote:
> > I actually see nothing wrong in division returning undef for a
> > dividend of 0. It's just as easy to check as doing an eval.
>
>Please don't do this. I would have to check every divide in
pe in the
> way that C blocks used to; if this is deemed inappropriate,
> this feature can simply be deleted, and the outer
> scope can be shared.
I suggest removing the rest of your quote, I don't think it adds anything.
--
Peter Scott
Pacific Systems Design Technologies
le
will throw exceptions everywhere, some won't, and some will do a
mixture. Just like now. You want to use a module, you read its interface
documentation and if it throws, you catch; or you use something else.
Maybe one day we can make a CPANTS [Comprehensive Perl Archive Network
Testing Service, under development] test for Fatal-checking, and authors
who do it will get better karma.
--
Peter Scott
Pacific Systems Design Technologies
e that division doen't return undef when the
dividend is 0 :-)
>(I realize that this may not be possible, but I'd like to have it
>kept as a possiblity. The call stack between the thrower and the
>catcher (where the catcher may have pragmatically asked for return
>style and the in
t; 10; $i++) {
> ...
> }
>
>is the same as this:
>
> $i = 1;
> while ($i < 10) {
> ...
> } continue {
> $i++;
> }
>
>(There is one minor difference: The first form implies a lexical scope for
>variables
>declared with my in the initialization expression.)
So no, what I'm proposing is not the same as anything currently in
Perl. But I think it's a good reason anyway (and why shouldn't continue
blocks share the same scope? Not so 'lexical', I suppose. Oh well.)
--
Peter Scott
Pacific Systems Design Technologies
> > else {
> > # rethrow the error
> > }
> > }
>
>Then you will be glad to know that RFC 88, in the not quite ready
>version two release, allows you do to just that.
"Allows" isn't the same as "should be the only way" though.
At 08:43 PM 8/19/00 -0600, Tony Olekshy wrote:
>Peter Scott wrote:
> >
> > Dave Rolsky wrote:
> > >
> > > Tony Olekshy wrote:
> > > >
> > > > die
> > > > If argument is anything else, raise a run-time
> > > >
s anything else, raise a run-time exception.
>
>So this probably shouldn't be the case.
This sounds alright; there's something very self-defeating about raising a
run-time exception from dying badly, if you see what I mean.
So the third case goes and the second one becomes, args are stringified and
joined on '', etc.
--
Peter Scott
Pacific Systems Design Technologies
At 09:40 PM 8/18/00 -0600, Tony Olekshy wrote:
>Peter Scott wrote:
> >
> > Tony Olekshy wrote:
> > >
> > > "An exception is not necessarily an error.\n" x 3;
> >
> > Note that 'error' is a vague term for which you have a specifi
a, so it knows to keep going)
catch $@->isa('Exception::Arithmetic') => { ... }
catch { ... }
Now the question is whether perl can tell that block isn't some expression
like an anonymous hash constructor. I'm no expert - my guess is that it
could tell by the time it discovered no comma following the block.
--
Peter Scott
Pacific Systems Design Technologies
only one base class to understand. If
stack traceback capture is expensive for a user module in Perl 5 that
doesn't mean it has to be in a core functionality in Perl 6.
--
Peter Scott
Pacific Systems Design Technologies
Reason: acknowledging many messages from people who thought this should be
implemented with the new switch statement.
--
Peter Scott
Pacific Systems Design Technologies
ion class reserves all instance variable
>and method names matching C. The following instance
>variables are defined.
>
>tag
>severity
>message
>debug
>object
>sysmsg
Why sysmsg? Why wouldn't a core exception use message? Why should someone
have to look at both?
&
share the same
lexical scope the same way that apparently disconnected while and continue
blocks do.
>Thanks. How much would you pay for this--but wait, there's more.
>Here's a quote from the Encyclopaedia of Software Engineering
>that's going into 88v2d2 (check there for
a of passing the exception stack in @_. If we use the RFC
63/Error.pm idea of passing the current exception in $_[0], then this falls
out naturally, and no need to follow a linked list. Gets my vote.
--
Peter Scott
Pacific Systems Design Technologies
At 05:18 PM 8/17/00 -0500, David L. Nicol wrote:
>Peter Scott wrote:
>
> > >Maybe $! becomes an alias for anything that gets thrown
> >
> > Actually it looks like $@ is doing that at the moment. *Confused*
>
>Make them all writable, then we can make user-defin
At 09:13 PM 8/16/00 -0600, Tony Olekshy wrote:
>Peter Scott wrote:
> >
> > Tony Olekshy wrote:
> > >
> > > try { TryToFoo; }
> > > catch { TryToHandleFailure; }
> > > finally { TryToCleanUp; }
> > >
cuting (go to step 5). Unlike catch blocks,
however, the current exception is not cleared at the end of the block.
5. If a current exception still exists, go to step 1 (start looking for
the next enclosing try block). This will happen if an exception was not
caught, or if a catch or fin
structure for the
exceptions.
But I was just asking something far more mundane, predicated on $!
surviving in much the same form: can its scope be expanded to be more than
just the current set of system calls?
--
Peter Scott
Pacific Systems Design Technologies
mes
>
> RFC 88 only introduces the try, throw, trap, catch, finally,
> and exception keywords, which are all traditionally related
> to exception handling. Also, "try" was chosen because of it
> neutral connotation (unlike "fail" for exa
At 10:11 AM 8/17/00 -0700, Larry Wall wrote:
>Peter Scott writes:
>: Do we want to come up with any modifications to the scope of $! (I'm not
>: talking about the dual string-number nature)? I've occasionally been
>: flummoxed by looking at it when there hadn't rea
gets lost. We're
>working on a couple mechanisms to keep (some) historic context around,
>while unwinding, for debugging purposes.
Actually, according to the documentation for caller(), it should do what I
want. It just doesn't yet.
--
Peter Scott
Pacific Systems Design Technologies
At 11:05 PM 8/16/00 -0400, Chaim Frenkel wrote:
> >>>>> "PS" == Peter Scott <[EMAIL PROTECTED]> writes:
> >> Also a use (within main or if it can work lexically) that would mean
> >> die_if_exception_thrown. Would treat the main routine as if it
At 10:56 PM 8/16/00 -0400, Chaim Frenkel wrote:
> >>>>> "PS" == Peter Scott <[EMAIL PROTECTED]> writes:
>
>PS> At 07:00 PM 8/16/00 -0400, Chaim Frenkel wrote:
> >> Perhaps, throw can carry a return value?
> >>
> >> throw {&q
n
>is aimed at the caller not at itself.
I think this has merit. We want throw to be able to throw farther. Maybe:
throw_up Exception::Foo(...);
to signify that we're going up instead of out.
Okay, :-) Got a better syntax? Would you want the option of throwing up n
(> 1) levels?
--
Peter Scott
Pacific Systems Design Technologies
At 07:10 PM 8/16/00 -0400, Chaim Frenkel wrote:
> >>>>> "PS" == Peter Scott <[EMAIL PROTECTED]> writes:
>
>PS> 1. When an exception is thrown perl looks for the enclosing try block; if
>PS> there is none then program death ensues.
>
>E
nt depending on a
context that's possibly miles away.
>
>
> >>>>> "PS" == Peter Scott <[EMAIL PROTECTED]> writes:
>
>PS> At 10:16 AM 8/16/00 -0400, Chaim Frenkel wrote:
> >> One issue that haven't seen addressed, is how to _not_ ha
alled it best when you pointed out the other problem with
daisy chaining.
--
Peter Scott
Pacific Systems Design Technologies
At 03:40 PM 8/16/00 -0500, Jonathan Scott Duff wrote:
>Well, those of you writing "exception" RFCs be sure and include this
>example in there somewhere (if it's relevant to your RFC of course).
Done.
>I'm done thinking about exceptions now.
Some of us are hoping to
cover from problems that are not explicitly
>hoisted outside of the try block.
This is a good point, and an argument for the try, catch, and finally
blocks sharing the same lexical scope the way that continue blocks do with
while. Another reason to call it 'continue' instead of 'finally' :-)
--
Peter Scott
Pacific Systems Design Technologies
this a problem?
Yes, I think it breaks the intuitive model. Let's leave $@ out of the
discussion for now, since it implies a place to store an exception which is
unnecessarily global. throws() outside a try block are caught by the catch
blocks of the next enclosing try block. See above.
--
Peter Scott
Pacific Systems Design Technologies
ck with a do statement. I think this will be needed rarely
enough that it is worth the slight obfuscation.
--
Peter Scott
Pacific Systems Design Technologies
hen want an
>Exception::Foo::DB subclass of it.
>
>My Exception::Class module on CPAN is pretty much all about being able to
>do this easily. It also implements a base exception but that's really for
>convenience and isn't necessary.
--
Peter Scott
Pacific Systems Design Technologies
catch E1 {
> might_throw_E2();
> }
> catch E2 {
> # we know exactly where this E2 came from!
> }
> }
It has an IMHO more serious ambiguity I have already pointed out.
--
Peter Scott
Pacific Systems Design Technologies
Redirected to -errors to save a thousand eyeballs.
At 11:42 AM 8/16/00 -0400, John Porter wrote:
>Peter Scott wrote:
> > At 05:33 PM 8/15/00 -0400, John Porter wrote:
> > >The thing I don't like about C++/Java try/catch syntax is the way
> > >the blocks are dais
other exceptions (omitted 1/4 the time)
} finally {
foo;# Even this block only appears 1/2 the time or less
}
>BTW, I hope you guys don't find me frustrating,
Heck no, this is how it's supposed to work.
> I'm just trying to
>decide what exception handling should look like in Perl to me.
--
Peter Scott
Pacific Systems Design Technologies
ns which return
values anyway and signal errors through $!. If we get open() modified as I
and others would like:
my $fh = open $filename;
how should we distinguish the one that throw()s from the one that doesn't?
--
Peter Scott
Pacific Systems Design Technologies
ible, it implies a level of
incestuousness that isn't good; what if the programmer puts something
besides a switch in the catch/else block? Is it supposed to look inside
that too to figure out if the exception was caught?
--
Peter Scott
Pacific Systems Design Technologies
At 02:01 PM 8/16/00 -0500, Jonathan Scott Duff wrote:
>On Wed, Aug 16, 2000 at 11:46:12AM -0700, Peter Scott wrote:
> > At 12:10 AM 8/16/00 -0500, Jonathan Scott Duff wrote:
> > >Why not have a special array that acts as an exception stack and each
> > >exception kn
At 11:52 PM 8/15/00 -0400, Chaim Frenkel wrote:
> >>>>> "PS" == Peter Scott <[EMAIL PROTECTED]> writes:
>
> >> Please include the comments about global variables and action at a
> distance.
>
>PS> I'm sorry, my brain is fried. Can y
to advanced, e.g. "unable to open /etc/passwd -
permission denied" causes "unable to update home directory" causes "unable
to modify user account" causes "unable to make global change - rolling back".
We can have both of these features. I still think the file and line arrays
are best for the first one.
--
Peter Scott
Pacific Systems Design Technologies
called from scott1.pl[1].
> $ = main::foo('Test') called from scott1.pl[8].
> $ = Try::try(CODE(0xca8830)) called from scott1.pl[9].
> $ = Try::try(CODE(0xca2418), 'catch', CODE(0x10b18ac))
> called from scott1.pl[8].
>
>If I'm n
73 matches
Mail list logo
