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-
Exceptions question
S04 says: Because the contextual variable C$! contains all exceptions collected in the current lexical scope, saying Cdie $! will throw all exceptions, whether they were handled or not. A bare Cdie/Cfail takes C$! as the default argument. Does this mean that $! is a container of some sort? - | 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
