"Richard J. Barbalace" <[EMAIL PROTECTED]> wrote:
> Jenda writes:
> > Well ... what about just ... making the eval{} block smaller?
> >
> > eval {
> > # Code where an error may occur
> > exception_causing_method();
> > };
> > if ($@) { ... }
> > # Code where I want to resume after handling the exception
> > print "Continuing....\n";
>
> Let's assume I'm trying to write a generalized resumptive error
> handler. I don't have control over what the eval block (or
> equivalent) will be, nor do I know how to modify its contents.
Well ... in that case ... I believe you can't.
> > Another thing ... what EXACTLY do you mean by "resume with
> > next statement". Say your eval{} block called function Foo(), which
> > called Bar(). And somewhere in the middle of Bar() occured an
> > exception.Do you want to continue with Bar(). Go back into Foo()
> > just below he call to Bar()? Go to the line of the eval{} block
> > below the call to Foo() ? I guess the last one, but ...
>
> The first: continue with the next line after where the exception was
> triggered, such that all state in any current functions is the same.
And what do you expect to get if the Bar() generated the exception
by calling die() to inform the caller that the parameters it got are
incorrect? Do you really want to force it to continue with incorrect
data?
Do you suppose to be able to access the lexical variables in Bar()
and change them so that the function will be able to go on? And
what about if you assume the exception was generated by Bar() (in
which case you'd need to modify $x), but it was actualy triggered
by Baz() (in which case you'd have to modify $y)? Think about
objects and inheritance, the Bar() could be a method and the type
of the object could sometimes be a subclass of X, not X itself.
IMHO it might make sense to resume with the next statement in
the eval block, since you kind of know what's going on in there, but
diving back into unknown functions looks too dangerous to me.
Anyway ... suppose you can do anything you want, could you
show us a piece of pseudocode as an example how do you want to
use that thing? What do you want to use it for?
IMHO it's all bad design, but that's not really since there IMO is no
way to implement it.
> > Anyway to tell the truth you could do this :
> >
> > eval {
> > print "Ahoj\n";
> > $y = 0;
> > $x = 1/$y;
> > LEJBL: print "Cau\n";
> > };
> > if ($@) {
> > print "ERROR: $@\n";
> > goto LEJBL;
> > }
>
> That's closer, but is it possible without inserting a label or using a
> goto? Assume the code that might trigger the error (the eval block or
> equivalent) is given to me.
No. And besides you ARE asking for a goto. You are asking for
GOTO one_statement_below_the_error. But I'm afraid
"one_statement_below_the_error" doesn't have a precise meaning.
> > P.S.: You come from VB? "On Error Resume Next", "On Error
> > Goto errHandler" and "Resume Next" ... I've never got used to that
> > crazy way of doing things.
>
> No, I've never used VB.
Lucky guy!
Jenda
=========== [EMAIL PROTECTED] == http://Jenda.Krynicky.cz ==========
There is a reason for living. There must be. I've seen it somewhere.
It's just that in the mess on my table ... and in my brain.
I can't find it.
--- me
--
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
