On Thu, Aug 10, 2000 at 05:11:17PM +0100, Graham Barr wrote:
I was more thinking of
eval {
# fragile code
}
else {# catch ALL exceptions
switch ($@) {
case __-isa('IO') { ... }
case
Redirected to perl6-language-flow.
At 12:23 PM 8/11/00 +0100, Graham Barr wrote:
On Thu, Aug 10, 2000 at 07:30:53PM -0700, Peter Scott wrote:
If we're really talking about new keywords, we wouldn't need a ; at the
end
of the last block; it's only needed at the moment because eval is a
I've moved this from perl6-language to perl6-language-flow.
Tony Olekshy wrote:
With the approach proposed in RFC 88 (Structured Exception
Handling Mechanism), you could write that as:
try {
} catch {
switch ($_[0]-name) {
case IO { ... }
I've moved this from perl6-language to perl6-language-flow.
Graham Barr wrote:
eval {
# fragile code
}
else { # catch ALL exceptions
switch ($@) {
case __-isa('IO') { ... }
case __-isa('Socket') { ... }
On Fri, Aug 11, 2000 at 09:36:32AM -0700, Peter Scott wrote:
Redirected to perl6-language-flow.
At 10:39 AM 8/11/00 -0400, John Porter wrote:
Piers Cawley wrote:
The (continue|always|finally|whatever) clause will *always* be
executed, even if one of the catch clauses does a die, so
Peter Scott wrote:
John Porter wrote:
Which makes me think that it would be nice if the continue block
could come before the catch block(s).
I get where you're going with this but it breaks the paradigm too
much. Now you need a 'finally' block again.
Sometimes you want before,
On Thu, Aug 10, 2000 at 06:43:30PM -0400, Chaim Frenkel wrote:
"GB" == Graham Barr [EMAIL PROTECTED] writes:
GB On Thu, Aug 10, 2000 at 04:34:50PM -0400, Chaim Frenkel wrote:
Nice.
The continue clause, I assume would re-raise an uncaught exception.
But, a big but. How does the
On Thu, Aug 10, 2000 at 07:30:53PM -0700, Peter Scott wrote:
So I'm thinking:
eval { ...
} catch Exception::Foo {
...
} catch Exception::Bar, Exception::Baz {
...
} catch {
... # everything else, but if this block is absent, uncaught exceptions
# head up the call stack
On Thu, Aug 10, 2000 at 07:47:47PM -0600, Tony Olekshy wrote:
With the approach proposed in RFC 88 (Structured Exception
Handling Mechanism), you could write that as:
try {
} catch {
switch ($_[0]-name) {
case IO { ... }
case Socket { ...
Graham Barr wrote:
If we're really talking about new keywords, we wouldn't need a ; at the end
of the last block; it's only needed at the moment because eval is a
function, not a keyword. I would vote for the keywords only because people
are going to forget the ; otherwise.
That
John Porter [EMAIL PROTECTED] writes:
Piers Cawley wrote:
The (continue|always|finally|whatever) clause will *always* be
executed, even if one of the catch clauses does a die, so you can use
this to roll back the database transaction or whatever else was going
on and restore any
"PC" == Piers Cawley [EMAIL PROTECTED] writes:
PC The (continue|always|finally|whatever) clause will *always* be
PC executed, even if one of the catch clauses does a die, so you can use
PC this to roll back the database transaction or whatever else was going
PC on and restore any invariants.
Chaim Frenkel [EMAIL PROTECTED] writes:
"PC" == Piers Cawley [EMAIL PROTECTED] writes:
PC The (continue|always|finally|whatever) clause will *always* be
PC executed, even if one of the catch clauses does a die, so you can use
PC this to roll back the database transaction or whatever else
At 10:34 AM 8/11/00 -0400, John Porter wrote:
But I'm against the idea of implicit rethrowing in any case.
Sure, other languages do it, but perl doesn't, and personally I think
it's a better paradigm.
We may have to disagree. If you don't have a clause to catch an exception,
semantically, it
On Fri, Aug 11, 2000 at 10:26:25AM -0700, Peter Scott wrote:
At 10:34 AM 8/11/00 -0400, John Porter wrote:
But I'm against the idea of implicit rethrowing in any case.
Sure, other languages do it, but perl doesn't, and personally I think
it's a better paradigm.
We may have to disagree.
"PC" == Piers Cawley [EMAIL PROTECTED] writes:
PC Good OO programming practice. Use polymorphism to replace switches. Then
PC when you subclass one of your classes you don't have to go 'round
PC rejigging the switch statements.
I haven't used OO in anger. But for me polymorphism is
Chaim Frenkel wrote:
Let the object determine the calling convention for the method.
I see very little reason to have two methods with different signatures.
Yes! That's the Perl philosophy! Right on!
--
John Porter
Chaim Frenkel wrote:
[ ... ] for me polymorphism is action-at-distance of the worst
stripe. Its the cheap and dirty way of doing OO. [...] I see
very little reason to have two methods with different signatures.
Method signatures and polymorphism are orthogonal. The latter
refers to
At 02:56 AM 8/10/00 -0500, Jonathan Scott Duff wrote:
Peter Scott writes:
try {
# fragile code
} catch Exception::IO with {
# handle IO exceptions
} catch Exception::Socket with {
# handle network exceptions
} otherwise {
# handle
On Thu, Aug 10, 2000 at 02:56:59AM -0500, Jonathan Scott Duff wrote:
Peter Scott writes:
try {
# fragile code
} catch Exception::IO with {
# handle IO exceptions
} catch Exception::Socket with {
# handle network exceptions
} otherwise {
On Thu, Aug 10, 2000 at 09:34:43AM -0700, Peter Scott wrote:
At 05:11 PM 8/10/00 +0100, Graham Barr wrote:
I was more thinking of
eval {
# fragile code
}
else { # catch ALL exceptions
switch ($@) {
Graham Barr wrote:
The catch syntax is less flexable, if you wanted to catch two
different types with the same code you are forced to either
* duplicate code
* put it in a sub, which is away from the statement.
* put a switch statement in the otherwise
Could catch lists of types:
On Thu, 10 Aug 2000 09:34:43 -0700, Peter Scott wrote:
Do you propose this solely to conserve keywords, or is there another
advantage? I find
try {
#
} catch Exception::Thingy with {
#
} catch Exception::Whatsit with {
#
}
Nice.
The continue clause, I assume would re-raise an uncaught exception.
But, a big but. How does the 'else' clause indicate that the exception
was handled?
A couple of possiblities
1. Undef $@. But that's a bit of extra work in each leg.
2. switch is 'slightly' special in an eval/else
"GB" == Graham Barr [EMAIL PROTECTED] writes:
GB On Thu, Aug 10, 2000 at 04:34:50PM -0400, Chaim Frenkel wrote:
Nice.
The continue clause, I assume would re-raise an uncaught exception.
But, a big but. How does the 'else' clause indicate that the exception
was handled?
GB By not
At 07:53 PM 8/10/00 +0200, Bart Lateur wrote:
p.s. I've always disliked the word "throwing" for errors, just to be a
complement to "catch". An error to me is something like a trapdoor,
where you unexpectedly fall through.
The only difference is the direction of travel :-) In both cases you
At 10:33 PM 8/10/00 +0100, Graham Barr wrote:
On Thu, Aug 10, 2000 at 04:34:50PM -0400, Chaim Frenkel wrote:
Nice.
The continue clause, I assume would re-raise an uncaught exception.
But, a big but. How does the 'else' clause indicate that the exception
was handled?
By not rethrowing
Peter Scott wrote:
So I'm thinking:
eval { ...
} catch Exception::Foo {
...
} catch Exception::Bar, Exception::Baz {
...
} catch {
... # everything else, but if this block is absent, uncaught exceptions
# head up the call stack
} continue {
... # Executed after
28 matches
Mail list logo
