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') { ... }
> c
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 diff
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
> "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 ac
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 d
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,
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 o
> "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 inva
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 rest
> On Fri, Aug 11, 2000 at 10:34:00AM -0400, John Porter wrote:
> > I support the idea of renaming the block eval as die, and leaving eval
Crimonentlies! I meant "try", of course. :-/ Freudian slip?
--
John Porter
On Fri, Aug 11, 2000 at 10:34:00AM -0400, John Porter wrote:
> I support the idea of renaming the block eval as die, and leaving eval
^^^
That would be interesting :)
> for string eval.
>
> But I'm against the idea of implicit rethrowing in any
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 invariants.
Which makes me think that it wou
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.
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 Sock
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 ca
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 b
Chaim Frenkel <[EMAIL PROTECTED]> writes:
> One thing that isn't addressed in any of the exception RFC's (and it
> may not be appropriate) is how to actually use it. Not in the syntactical
> or semantic meaning. But in how to use it practically.
>
> Given six lines of code within a trapping cont
One thing that isn't addressed in any of the exception RFC's (and it
may not be appropriate) is how to actually use it. Not in the syntactical
or semantic meaning. But in how to use it practically.
Given six lines of code within a trapping context, how does one
end up with the invariant restored
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
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
Peter Scott wrote:
>
> try {
> } catch Exception::IO with {
> } catch Exception::Socket with {
> } otherwise {
> };
Jonathan Scott Duff wrote:
>
> try {
> } catch {
> switch ($EXCEPTION->name) {
> case IO { ... }
> case Socket { ... }
>
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 do
At 05:44 PM 8/10/00 +0100, Graham Barr wrote:
>Well what is the difference between try and eval ?
There isn't any. I could have sworn I once read that the block eval was so
different from the string eval that Larry wanted to use 'try', but didn't
want to add another keyword, but later wished h
At 05:44 PM 8/10/00 +0100, Graham Barr wrote:
>In fact the syntax could be
>
> eval {
> }
> continue {
> }
>
> switch ($@) {
> } if $@;
>
>I just don't see the need to make perl look like other languages just for
>the sake of makeing it look like other languages.
No, I wasn't thinking
> "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?
G
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 it. ie if it does not want to handle the
error
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 block.
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 {
> #
>
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 type
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 ($@) {
>
At 05:11 PM 8/10/00 +0100, Graham Barr wrote:
>I was more thinking of
>
> eval {
> # fragile code
> }
> else { # catch ALL exceptions
> switch ($@) {
> case __->isa('IO') { ... }
> case __->isa
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
> > } oth
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 {
> >
Peter Scott writes:
> try {
> # fragile code
> } catch Exception::IO with {
> # handle IO exceptions
> } catch Exception::Socket with {
> # handle network exceptions
> } otherwise {
> # handle other exceptions
> };
What would the difference betw
34 matches
Mail list logo
