At 02:33 PM 5/2/02 -0600, Jim Cromie wrote:
>eval {} or carp "$@ blah";
>
>it seems to work, and it reads nicer (to my eye) than
>
>eval {}; if ($@) {}
% perl -le 'eval { print "No exceptions here"; 0 } or warn "$@ blah"'
No exceptions her
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
re resolved? Let's not start down that path.
--
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
alled it best when you pointed out the other problem with
daisy chaining.
--
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
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
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
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 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
* distributive would be something written on a bathroom wall at
Venice beach.
In between we have
@a = @b || @c;
which goes according to taste. Mebbe a slightly cleaned-up version of
Flesh Gordon (which has been airing on the Space Channel in Canada, but
would never see the light of day on the equivalent cable tier in the US).
--
Peter Scott
Pacific Systems Design Technologies
don't act like normal subroutines).
--
Peter Scott
Pacific Systems Design Technologies
verywhere. And even if it were
>why should any other program use the same epoch.
>
>The only valid interchange would be to specify the date unambiguously,
>for example the ISO MMDDHHMMSS.fff
ISO 8601. http://www.cl.cam.ac.uk/~mgk25/iso-time.html
--
Peter Scott
Pacific Systems Design Technologies
drag on forever they may turn ugly.
Besides, the -internals folk are waiting to see what they need to get going
on. And I would think we'd want a time when we knew Larry could get going
on the RFCs without wondering whether something else was going to romp out
of the starting gate.
--
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
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
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
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
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
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
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 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
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
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
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
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
Reason: acknowledging many messages from people who thought this should be
implemented with the new switch statement.
--
Peter Scott
Pacific Systems Design Technologies
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
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
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?
&
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
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
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
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
At 09:13 PM 8/16/00 -0600, Tony Olekshy wrote:
>Peter Scott wrote:
> >
> > Tony Olekshy wrote:
> > >
> > > try { TryToFoo; }
> > > catch { TryToHandleFailure; }
> > > finally { TryToCleanUp; }
> > >
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
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 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
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
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
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
ly. I meant to say that I don't want to truncate the
lines inside the script, because it's already too late then. Think of this
as a safety mechanism, like taint.
--
Peter Scott
Pacific Systems Design Technologies
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
> > > >
At 12:01 AM 8/20/00 -0400, Bryan C. Warnock wrote:
>On Sat, 19 Aug 2000, Peter Scott wrote:
> > -io guys, I've been looking through your archives at the line discipline
> > stuff and I don't see this there: what do you think? The proposal is
> for a
> > mode
han that would be an error of some
kind." Yes, Perl can handle many more characters than that before it
starts to have problems, but so what. Maybe I have scripts where I would
set it to 1_000_000_000 but that would still make sense.
[followups to -io only please]
--
Peter Scott
Pacific Systems Design Technologies
like
read().
Would really like a feature that said, "<> will get characters until this
many have been retrieved, or newline, whichever comes first." Sound
reasonable?
--
Peter Scott
Pacific Systems Design Technologies
f someone throws a gargantuan number of characters at FH without
a newline. The $/ = ref_to_int feature is exactly the kind of feature I
was expecting to do this and I was disappointed that it didn't.
--
Peter Scott
Pacific Systems Design Technologies
At 05:12 AM 8/19/00 +1000, Damian Conway wrote:
>> The main downside of accessors is that you can't (currently) say
>>
>> local $obj->attribute = 2;
>
>Even if C returns an lvalue???
If it does, how do you localize it? What would that mean?
--
Pe
t I thought I'd shake the branches anyway and see what fell out.
I'm sending this to -language because folk are probably expecting just
exception stuff on -errors; but I think it would be best for respondents to
redirect to -errors.
--
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.
for my($key,$val) = (%hash) { ... }
I would so love to have this.
--
Peter Scott
Pacific Systems Design Technologies
At 10:06 AM 8/20/00 -0400, Bryan C. Warnock wrote:
>On Sun, 20 Aug 2000, Peter Scott wrote:
>
> > I read that before I made my posting; it looked to me that :block was
> > specifying a fixed-length read independent of line terminators, i.e., same
> > behavior as $/ =
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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 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
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
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
>"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
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
>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
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
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
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: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
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
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
ng etc
Yes, this is losing information; the former $! is no longer around. I
contend that it's eliding functionality that is seldom, if ever, used, in
favor of a natural simplification. There's one place where an error
message shows up. One. No need to figure out what kind of thing failed.
--
Peter Scott
Pacific Systems Design Technologies
addressed is table 3-3 on p. 97 of Camel III (unlabelled table on p. 84 of
Camel II)?
--
Peter Scott
Pacific Systems Design Technologies
At 06:14 PM 8/24/00 -0400, Michael G Schwern wrote:
>Okay, devil's advocate.
>
>Paragraphs.
>
> sub legal {
> print << Attention criminal slacker, we have yet
> to receive payment for our legal services.
>
> Love and kisses
> FOO
> }
At 11:32 AM 8/25/00 +0200, Johan Vromans wrote:
>Nathan Torkington <[EMAIL PROTECTED]> writes:
>
> > Read my lips: GOOD THING.
>
>Do we have an RFC yet that proposes Perl to be easier parsable?
We have one proposing nearly the opposite: RFC 28.
--
Peter Scott
Pacific Systems Design Technologies
ng our team of legal beagles
> straight for your scrofulous crotch.
>
> xx oo
> FOO
>
>you mean?
Right; I was proposing new syntax for recognizing the terminator; it would
not have any effect on the intervening text.
--
Peter Scott
Pacific Systems Design Technologies
At 05:41 PM 8/24/00 -0600, Tom Christiansen wrote:
>But you don't need that when you can and possibly should just write this:
>
> print <<"EOF" =~ /^\s*\| ?(.*\n)/g;
> | Attention criminal slacker, we have yet
> | to receive payment for our legal s
wouldn't you want to just get rid of the whole construct? Is there any
need for it?
--
Peter Scott
Pacific Systems Design Technologies
kes the copying easier to spot since it's up
front and you don't have to scan to the end to discover it.
--
Peter Scott
Pacific Systems Design Technologies
te to the irony and it will simply appear
more consistent. If anyone has written a subroutine that does such
different things in each context that it would be broken by this, well, I
would like to see that code and ask them a few questions...
--
Peter Scott
Pacific Systems Design Technologies
n by this sentence).
> > =head1 REFERENCES
> >
> > L
>
>What about Damian's want (RFC 21)
Yes, thanks.
--
Peter Scott
Pacific Systems Design Technologies
ined q[a-z]// (using a letter that
hadn't already been taken), where you get to specify the actions of =~ and
probably more operators? Sounds like it has a lot in common with operator
overloading - maybe even just an extension to overload.pm?
--
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
he
same way in Perl 6 as it does now, so you will indeed be able to do what
you propose. (This is my position and RFC 88's position, but there are
disagreements.)
(Nearly) everrrybuddy heppy :-)
--
Peter Scott
Pacific Systems Design Technologies
ether this construct would really give the parser problems
or whether looking ahead for the block will disambiguate.
Unfortunate that (I assume that) it couldn't extend to the modifier form as
well.
--
Peter Scott
Pacific Systems Design Technologies
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
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
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
wholeheartedly support the RFC; but it opens a can of worms
that should be addressed. Perhaps in another RFC. Do any other (Damian)
RFCs on (Damian) prototyping impact (Damian) this area?
--
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
as made Perl a lot easier to understand IMHO.
--
Peter Scott
Pacific Systems Design Technologies
101 - 200 of 272 matches
Mail list logo
