Re: Exceptions question
On Wed, 25 Feb 2009, Larry Wall wrote: On Thu, Feb 26, 2009 at 02:05:28PM +1100, Timothy S. Nelson wrote: Does this mean that $! is a container of some sort? It's an object, which (in the abstract) can contain anything it jolly well pleases. The main question beyond that is how it responds if used like one of the standard containers. I don't see any great motivation for that offhand, but we'll have to examine the use cases as things progress. Hmm. S04 says: : That implicit topic is the current exception object, also known as C$! and also: : Because the contextual variable C$! contains all exceptions collected in : the current lexical scope... ...that implies to my mind that $! is an exception object, but that an exception object can contain more than one exception. Is that correct? But the spec also says: : Exceptions are not resumable in Perl 6unless the exception object does the : CResumable role. ...so Resumable is attached to a group of exceptions, not a single exception. Now I'm really confused :). My suggested solution would be to change $! to an exception container object. But then we have to use it in the implicit given in the CATCH block. If we used an any() Junction, would that do what we want? :) - | Name: Tim Nelson | Because the Creator is,| | E-mail: wayl...@wayland.id.au| I am | - BEGIN GEEK CODE BLOCK Version 3.12 GCS d+++ s+: a- C++$ U+++$ P+++$ L+++ E- W+ N+ w--- V- PE(+) Y+++ PGP-+++ R(+) !tv b++ DI D G+ e++ h! y- -END GEEK CODE BLOCK-
Re: Exceptions question
On Thu, 26 Feb 2009, Timothy S. Nelson wrote:
My suggested solution would be to change $! to an exception container
object. But then we have to use it in the implicit given in the CATCH block.
If we used an any() Junction, would that do what we want?
Ok, Moritz told me on IRC that this won't work. My next suggestion is
to have @! be an array that replaces $! completely (freeing it up for $!foo
things), and then have the CATCH block implicitly do:
given(any(@!)) {
...
}
:)
-
| Name: Tim Nelson | Because the Creator is,|
| E-mail: wayl...@wayland.id.au| I am |
-
BEGIN GEEK CODE BLOCK
Version 3.12
GCS d+++ s+: a- C++$ U+++$ P+++$ L+++ E- W+ N+ w--- V-
PE(+) Y+++ PGP-+++ R(+) !tv b++ DI D G+ e++ h! y-
-END GEEK CODE BLOCK-
Re: Exceptions question
Em Qui, 2009-02-26 às 22:26 +1100, Timothy S. Nelson escreveu:
given(any(@!)) {
}
using junctions on exception handling doesn't seem like a good idea to
me, because it is too much of a basic feature... but...
for @! {
}
might provide the needed semantics...
OTOH, I think it would be sane to have $! representing the last
exception, so you can still use
my $file = open 'file.txt' or die $!;
no matter how many unthrown exceptions you have in that block.
daniel
Re: Exceptions question
Em Qui, 2009-02-26 às 08:55 -0300, Daniel Ruoso escreveu:
for @! {}
might provide the needed semantics...
After sending this mail I've just realized I don't know exactly which
are the needed semantics...
what happens if you have several unthrown exceptions in the block, does
it throw every one of them? in sequence? autothreading? what happens if
one CATCH handles one of the exception but only an outer CATCH handles
the other?
I'm not sure there is a sane way of having several unthrown exceptions
at the same block, so I think the best thing we can do is to throw the
first unthrown exception if a second exception happens...
meaning... if $! is already set with an unhandled exception that
exception is thrown. If that happens to be a resumable exception, the
code can be resumed and the other exception will be stored in $! for a
later evaluation.
daniel
Re: Exceptions question
On Thu, 26 Feb 2009, Daniel Ruoso wrote:
Em Qui, 2009-02-26 às 08:55 -0300, Daniel Ruoso escreveu:
for @! {}
might provide the needed semantics...
After sending this mail I've just realized I don't know exactly which
are the needed semantics...
what happens if you have several unthrown exceptions in the block, does
it throw every one of them? in sequence? autothreading? what happens if
one CATCH handles one of the exception but only an outer CATCH handles
the other?
I'm not sure there is a sane way of having several unthrown exceptions
at the same block, so I think the best thing we can do is to throw the
first unthrown exception if a second exception happens...
meaning... if $! is already set with an unhandled exception that
exception is thrown. If that happens to be a resumable exception, the
code can be resumed and the other exception will be stored in $! for a
later evaluation.
Moritz suggested on IRC (in different words) that, as Match objects
can do the Associative role, that maybe Exception objects could do the
associative role as well. That would mean that we would retain $!, but would
still have the others there, just as $/ is the most recent Match, but can also
be a container of matches.
That doesn't answer your question about how to handle multiple
exceptions, though :).
-
| Name: Tim Nelson | Because the Creator is,|
| E-mail: wayl...@wayland.id.au| I am |
-
BEGIN GEEK CODE BLOCK
Version 3.12
GCS d+++ s+: a- C++$ U+++$ P+++$ L+++ E- W+ N+ w--- V-
PE(+) Y+++ PGP-+++ R(+) !tv b++ DI D G+ e++ h! y-
-END GEEK CODE BLOCK-
Re: Exceptions question
On Thu, Feb 26, 2009 at 02:05:28PM +1100, Timothy S. Nelson wrote: Does this mean that $! is a container of some sort? It's an object, which (in the abstract) can contain anything it jolly well pleases. The main question beyond that is how it responds if used like one of the standard containers. I don't see any great motivation for that offhand, but we'll have to examine the use cases as things progress. Larry
Re: Exceptions on hypers
Aaron Sherman wrote:
Damian Conway wrote:
@bar».foo if $baz;
That brought to mind the question that I've had for some time: how are
exceptions going to work on hyper-operators?
Will they kill the hyperoperation in-progress? e.g. what will $i be:
Corrected example follows (there were supposed to be 10 elements):
my $i = 0;
class A { method inci() { die if $i++ 5 } }
my @aoa = map {A.new} 1..10;
try { @aoa.inci; }
say $i;
We now return you to your regularly scheduled question, already in progress:
Is it even possible to know, or is it entirely dependent on the
implementation? And what do multiple, successive dies within the same
try block do?
Re: Exceptions on hypers
On Wed, Oct 04, 2006 at 10:35:05AM -0400, Aaron Sherman wrote:
: Damian Conway wrote:
:
:@bar».foo if $baz;
:
: That brought to mind the question that I've had for some time: how are
: exceptions going to work on hyper-operators?
:
: Will they kill the hyperoperation in-progress? e.g. what will $i be:
:
: my $i = 0;
: class A { method inci() { die if $i++ 5 } }
: my Array of A @aoa;
: try { @aoa.inci; }
: say $i;
:
: Is it even possible to know, or is it entirely dependent on the
: implementation? And what do multiple, successive dies within the same
: try block do?
An uncaught exception is going to blow you out of the hyperoperator
when it's partway done, just like any other operator. Since a
hyperoperator is a promise that you don't care about ordering of side
effects, any code that relies on a particular implementation's ordering
of side effects is erroneous.
Which is all an excellent argument for unthrown exceptions being
the norm. Then the hyper can proceed to completion and you just
have to be careful how you use the resulting undefined values.
For hypers that must produce unboxed native types, you don't have
the undef option, but at least IEEE floaters give you NaN and Inf.
This also tells me that we'll occasionally want to turn normally fatal
exceptions into unthrown exceptions. Fortunately, Perl 6 specifies
that CATCH blocks run before the stack is unwound, so this should be
possible in theory. Of course, this is not guaranteed to work unless
the undef value is returned immediately to the hyperoperator manager,
since the called code may not have anticipated that it might have to
continue with an undefined value.
All the more reason to encourage use of fail rather than die.
Larry
Re: Exceptions
This is more of a language thang, so I've redirected your message there [here]. The most fundamental feature throwing an exception is that it transfers program execution from the call site. Allowing the caller to resume execution at that site is a very dangerous form of action at a distance. According to you. :-) I think you'd be better off a giving the caller an explicit way to inhibit throwing an exception. That is, use program design rather than language features to provide this functionality. e.g., a delegate: $ex = new My::Exception: ...; die $ex unless .delegate .delegate.should_ignore_ex($_, $ex)); Not only is the above pattern clearer to read and less afflicted by action at a distance, but it provides a wider bidirectional interface. It also has high inertia and is pretty verbose for error reporting. The thing about reporting errors is that it needs to be short, easy to type, easy to think about, or else people won't do it. Everyone did error checking in Perl 5 because it was a simple little Cor die. But I think you've got one thing right: giving the exception thrower control. The thing about Cdie is that it denotes a fatal error -- saying Cdie in a function is basically saying I can't continue after this... so you Iprobably shouldn't be allowed to continue it. If an error isn't fatal, you're supposed to use Cwarn. So, maybe what's needed is a Cwarn catcher (CWARNCATCH... eew), where Cwarn would throw an exception object with an attached continuation. And of course, if a warning reached the top of the stack without being caught, it would print itself and invoke its continuation. Luke
Re: Exceptions
Luke Palmer [EMAIL PROTECTED] writes: This is more of a language thang, so I've redirected your message there [here]. The most fundamental feature throwing an exception is that it transfers program execution from the call site. Allowing the caller to resume execution at that site is a very dangerous form of action at a distance. According to you. :-) I think you'd be better off a giving the caller an explicit way to inhibit throwing an exception. That is, use program design rather than language features to provide this functionality. e.g., a delegate: $ex = new My::Exception: ...; die $ex unless .delegate .delegate.should_ignore_ex($_, $ex)); Not only is the above pattern clearer to read and less afflicted by action at a distance, but it provides a wider bidirectional interface. It also has high inertia and is pretty verbose for error reporting. The thing about reporting errors is that it needs to be short, easy to type, easy to think about, or else people won't do it. Everyone did error checking in Perl 5 because it was a simple little Cor die. But I think you've got one thing right: giving the exception thrower control. The thing about Cdie is that it denotes a fatal error -- saying Cdie in a function is basically saying I can't continue after this... so you Iprobably shouldn't be allowed to continue it. If an error isn't fatal, you're supposed to use Cwarn. What's being said is I can't continue after this with the data and code as they are. I can envisage Perl code running in a Smalltalk like environment where catching such an exception would throw up a debugger allowing the programmer to alter either a variable, the exceptional code, or just faking a return value and either retrying or continuing. This kind of approach makes for a remarkably powerful way of doing, say, test first programming. You just write your test and start the test suite running, when this throws an 'unknown method exception' or whatever, you use the debugger to implement/stub out the method in question, retry, and repeat until the test stops throwing exceptions. So, maybe what's needed is a Cwarn catcher (CWARNCATCH... eew), where Cwarn would throw an exception object with an attached continuation. And of course, if a warning reached the top of the stack without being caught, it would print itself and invoke its continuation. In theory a thrown exception can include everything that's known about the runstate of your program at the time the exception was thrown. And it can't know how that information may be used by some handler up the chain. This implies to me that the correct behaviour when throwing a generic exception is to bundle up all the information available and leave it up to the catcher to decide what to do with it. Yes, this does mean that the catcher might be able to do some Really Stupid things, but if you don't open the door to Mr Stupid you are in danger of slamming it in the face of Mr Powerful. It seems to me that Perl's usual approach in such situations has been to leave the door unlocked... -- Piers
Re: Exceptions
Luke Palmer wrote:
So, maybe what's needed is a Cwarn catcher (CWARNCATCH... eew),
where Cwarn would throw an exception object with an attached
continuation. And of course, if a warning reached the top of the
stack without being caught, it would print itself and invoke its
continuation.
I thought I'd try and see how this would work. A toy example:
implementing saturated arithetic uses exceptions:
sub incr ( int $a is rw is checked )
{
$a++;
CATCH {
when IntegerOverflow { $a = int.max };
default { throw }
}
}
This would work for a single variable, but no extend it to do a few more:
{
$a++;
$b++;
$c++;
WARNCATCH
{
when IntegerOverflow { .recover = int.max; .resume };
}
}
I think it is safe to assume that an exception object that provides a
.resume method will also provide methods/attributes to allow a hander to
take corrective action before resuming. Hence the .recover attribute
would need be a standard feature of all exceptions: it just happens to
be the name used by the IntegerOverflow object.
How would this look from the thrower's side? I can think of a few
possibilities. I think we currently have Cthrow to throw a terminal
exception. Cwarn isn't right, because Cdie isn't Cthrow. So what's
a less ballistic approach to a throw? A Cbounce, Cpong, Cpanic?
I'm not sure of the keyword, but useage could look something like:
sub postfix:++ (int $a is rw)
{
if ($a == int.max)
{
lob IntegerOverflow.new( var=$a, overshoot=1 )
}
else
{
$a = $a + 1
}
return $a;
}
I think it could work, and the rope's not really enough to hang the unwary.
Dave.
p.s. the example is a toy, but saturated arithmetic is useful, and often
supported in the instruction set of the host cpu --- any chance of it
being build into parrot/jit? Ditto for overflow exceptions.
Re: Dual nature (was Re: Exceptions and Objects)
At 07:00 PM 8/16/00 -0400, Chaim Frenkel wrote:
Perhaps, throw can carry a return value?
throw {"return value"} $exception;
If there is an active try/catch context then the $exception would
be propogated, otherwise $@ would get loaded with $exception and
the return value would be the specified value.
If not specified then it would be the same as a return with no
arguments.
But what of RFC 70, which wants the option for exceptions in system calls
to cause program death?
Also I don't like code deciding to do something different depending on a
context that's possibly miles away.
chaim
"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_ have exceptions.
I want to use a core module (non-core can do anything they want) but
I'd like to write it in procedural mode.
try {
$obj-method...
}
catch { }
finally {}
or
$status = $obj-method...
And have both work properly.
PS Yes, I want this too. The method could certainly look to see whether
it's
PS in void context and throw an exception if so; in fact Jarkko suggested
this
PS just now on p5p:
Mental note: in Perl 6 system calls by default should die if their
return value isn't checked.
PS Short of setting some global switch, I don't see how else to do
PS it. However, this doesn't address the issue of functions which return
PS values anyway and signal errors through $!. If we get open() modified
as I
PS and others would like:
PS my $fh = open $filename;
PS how should we distinguish the one that throw()s from the one that doesn't?
--
Peter Scott
Pacific Systems Design Technologies
Re: Dual nature (was Re: Exceptions and Objects)
"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 {"return value"} $exception;
If there is an active try/catch context then the $exception would
be propogated, otherwise $@ would get loaded with $exception and
the return value would be the specified value.
If not specified then it would be the same as a return with no
arguments.
PS But what of RFC 70, which wants the option for exceptions in system calls
PS to cause program death?
PS Also I don't like code deciding to do something different depending on a
PS context that's possibly miles away.
That would be a choice of the main program, Either wrap itself in a try.
or a pragma that probably would look nicer.
Actually, this would be no worse than any other perlian context. If
the effect of a scalar context could make a remote literal ',' become
a comma operator, than this can't be any worse.
Another way to look at it, is that it _doesn't_ effect the callee. The
callee wishes to terminate the function, and the next
statement/expression will not be executed. The callee supplies the
result. The caller is deciding how the results will be delivered.
Hmm, I'm sure that some authors who like the error return style would
like the pragma to force return context so that they don't have
to wrap everything in a try.
chaim
--
Chaim FrenkelNonlinear Knowledge, Inc.
[EMAIL PROTECTED] +1-718-236-0183
Re: Exceptions and Objects
Jonathan Scott Duff [EMAIL PROTECTED] writes: On Sun, Aug 13, 2000 at 10:51:24PM -0700, Peter Scott wrote: Could be. I'd be interested in seeing non-OOP proposals that do what I want exceptions to do, I have a hard time imagining one. Well, what is it that you want exceptions to do? What does it mean for an exception to have semantics? When an exception is thrown does something special happen whether it's caught or not? Yes. In my proposal, if it's caught, the catcher examines the exception object. If it isn't caught, the program dies with the message attribute as text. This doesn't show that the exception object itself has any semantics. If the catcher examines, the object is being passive. Does the object *do* anything? I want it to be able to. Depends on how you write it... -- Piers
Re: Exceptions and Objects
Jonathan Scott Duff wrote:
On Sun, Aug 13, 2000 at 07:27:47PM -0700, Peter Scott wrote:
An error has text associated with it, but also a bunch of other
attributes.
So it's a structured data type... where does OOP come into play?
1. It allows you to *extend* the base type with new attributes
without having to re-implement all the base attributes.
2. It allows you to *extend* the base type with new methods that
can, say, compute predicates based on the object's attributes.
Then, you can say things like:
if ( $@-isa(MyException) $@-CanFoo ) { ... }
3. Is allows you to *override* base class behaviour, for example,
by changing the way stringification works for some classes, or
by modifying a constructor to do some sort of logging, for some
class of exceptions.
They fall naturally into different classes, some of which have
subclasses (a File error is-a IO error).
This, to me, seems a mere matter of naming. Was it that OOP already
had a hierarchical naming system and so it was used?
Once the other good reasons for OO exceptions come into play, you
may as well take advantage of the serendipity.
What does it mean for an exception to have semantics? When an
exception is thrown does something special happen whether it's
caught or not?
$@-CanFoo is an example of semantics that determines whether or
not the exception is caught; stringification may be an example
of semantics that comes into play when an exception is caught.
Yours, c, Tony Olekshy
Re: Exceptions and Objects
Piers Cawley wrote: Tony Olekshy writes: Peter Scott wrote: An exception is an 'error'. That's already a vague concept. I'll say it's vague. There are certainly uses for an exception to trigger non-local success, not an error at all. In fact, there are whole programming techniques based on such uses. Just because most of us usually use exceptions to handle errors, that doesn't mean Perl should not support other uses. Ah, the 'Bloody hell it worked! That's exceptional' style of programming? Yup. But I couldn't have said it better than you just did. Yours, c, Tony (TIMTOWTDI) Olekshy
Re: Exceptions and Objects
Jonathan Scott Duff wrote:
On Mon, Aug 14, 2000 at 04:09:41AM -0600, Tony Olekshy wrote:
$@-CanFoo is an example of semantics that determines whether or
not the exception is caught; stringification may be an example
of semantics that comes into play when an exception is caught.
Ah, this is why I started asking I guess. Some people were proposing
a try/catch like the following:
try { }
catch SomeException { }
catch SomeOtherException { }
finally { }
which seems to only catch exceptions based on name. Which implies to
me that, for exceptions to have useful semantics, they'd have to be
rethrown after they're caught. I like the following, but it would
also seem that exceptions that aren't handled here would have to be
rethrown so that an upstream catch could handle them.
try { }
catch { # ALL exceptions
switch ($@) {
case ^_-name eq 'IO' { ... }
case ^_-canFoo { ... }
throw $@; # No cases matched, rethrow
}
}
finally { }
This is why RFC 88 is working on syntax and semantics for:
try { ... } except sub { $_[0]-CanFoo } = catch { ... }
which *does* unwind if $_[0] can't Foo (or, if $_[0]-CanFoo or the
catch clause throws).
Yours, c, Tony Olekshy
Re: Exceptions and Objects
At 12:22 PM 8/12/00 -0500, Jonathan Scott Duff wrote: On Sat, Aug 12, 2000 at 07:07:18AM -0600, Tony Olekshy wrote: I also submitted RFC 96, which tries to address the stuff that is needed for extending beyond builtins while maintaining a standard Perl OO implementation and seperating the exception handling stuff from the exception class. Rereading RFC 80, I realize that they are closer than I thought, each emphasising different aspects of the problem. I've read this thread with some interest and I'm puzzled by something. Why are "objects" and "exceptions" always mentioned in the same breath? Does one need objects to have exceptions? Pretty much. It screams O-O for these reasons: An exception is an 'error'. That's already a vague concept. An error has text associated with it, but also a bunch of other attributes. They fall naturally into different classes, some of which have subclasses (a File error is-a IO error). Users want to define their own kinds while reusing the semantics of the base class. Bingo. -- Peter Scott Pacific Systems Design Technologies
