Re: English language basis for throw
Peter Scott wrote: Only one of them needs to be right. As long as one is right, there is no problem. Right, I was just pointing out that it's harder for people to divine which one we picked without recourse to the documentation. Yes; unfortunately, this problem exists generally, especially wrt Perl. :-/ -- John Porter
Re: error handling and syntax extension
or AUTOLOAD can be defined in terms of Ccatch
and overloaded that way, rather than being its own
kind of magic.
catch "AUTOLOAD-$classname-$polymorphicsignature" {...
Jonathan Scott Duff wrote:
On Wed, Aug 16, 2000 at 12:15:30PM -0500, David L. Nicol wrote:
If "catch" can be defined DURING PARSING
and SYNTAX ERRORS are catchable
error handling can be used to define otherwise
undefined syntax, becoming a macro language.
And AUTOLOAD can go away too! :-)
-Scott
--
Jonathan Scott Duff
[EMAIL PROTECTED]
--
David Nicol 816.235.1187 [EMAIL PROTECTED]
Useless use of a void in constant context
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: Towards a reasonable unwinding flow-control semantics.
At 07:10 PM 8/16/00 -0400, Chaim Frenkel wrote: "PS" == Peter Scott [EMAIL PROTECTED] writes: PS 1. When an exception is thrown perl looks for the enclosing try block; if PS there is none then program death ensues. Err, if there isn't one. Don't throw the exception. Stop processing but don't throw. You are imposing a style on your caller. ??? I don't get this at all. A message would be appropriate (ala, die or warn) Also a use (within main or if it can work lexically) that would mean die_if_exception_thrown. Would treat the main routine as if it were wrapped in a try block that doesn't catch any exceptions. RFC 63 already states this. Uncaught exceptions at the outermost level are dies. (And there is a very close relationship between die and throw.) -- Peter Scott Pacific Systems Design Technologies
Re: yoda 2
"DLN" == David L Nicol [EMAIL PROTECTED] writes: DLN =head2 eval/die remains perfectly workable DLN as "die" is a perfectly serviceable method or raising an exception. Actually, die is pretty nasty. Modules can't use it. Another mechanism that means, short circuit, but let the user know why. That selects either a non-local goto or a return mechanism depending upon context. (Dynamically within the control of a try/eval, or under pragmatic control requesting the non-local mechanism.) chaim -- Chaim FrenkelNonlinear Knowledge, Inc. [EMAIL PROTECTED] +1-718-236-0183
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: Towards a reasonable unwinding flow-control semantics.
"PS" == Peter Scott [EMAIL PROTECTED] writes:
PS At 07:10 PM 8/16/00 -0400, Chaim Frenkel wrote:
"PS" == Peter Scott [EMAIL PROTECTED] writes:
PS 1. When an exception is thrown perl looks for the enclosing try block; if
PS there is none then program death ensues.
Err, if there isn't one. Don't throw the exception. Stop processing but
don't throw. You are imposing a style on your caller.
PS ??? I don't get this at all.
Consider a module A uses try all over the place. Module B uses procedural
call, and accepts callbacks from A.
The callbacks from A raise/throw around B. B's author would like to
be able to do some cleanup, restore invariants, whatever, after a
callback fails. By allowing the caller to determine how the errors
are delivered we are allowing the author more freedom in his design.
So all he would need to add would be a lexical pragma, use exception 'return'
A message would be appropriate (ala, die or warn)
Also a use (within main or if it can work lexically) that would mean
die_if_exception_thrown. Would treat the main routine as if it were
wrapped in a try block that doesn't catch any exceptions.
PS RFC 63 already states this. Uncaught exceptions at the outermost
PS level are dies. (And there is a very close relationship between
PS die and throw.)
But I don't want that. Why? Throws are error returns not death.
A module author should _never_ invoke die. How does the module author
know what the caller wants to be done.
I just don't want to be forced into scattering lots of little try{}
just to get back to my error return style of coding.
chaim
--
Chaim FrenkelNonlinear Knowledge, Inc.
[EMAIL PROTECTED] +1-718-236-0183
Re: RFC 63 (v3) Exception handling syntax
Peter Scott wrote:
If that were so, even without the ignore() function, I could just say
sub Exception::IO::throw { 'do nothing' }
and kill it that way.
Right. Just like overriding core die. At that point you can
change the semantics in such a way as to turn your code into
nonsense.
I am open to suggestions on whether we should make it impossible for
someone that determined to shoot themselves in the foot to do so. My
feeling is that someone smart may have a good reason for doing it (in
their own code, not in a module given to others), and someone dumb
deserves what they get for doing something so blatantly stupid.
I agree, we should not make it impossible, but I believe we should make
it relatively difficult to do accidentally (much like the forgotten
re-throw or function return code checking problems).
Yours, c, Tony Olekshy
Re: Towards a reasonable unwinding flow-control semantics.
Executive summary: I no longer want catch blocks to "daisy chain"
after a exception is thrown in a catch block. Thanks to everyone
who has helped me see the light on this.
Peter Scott wrote:
At 01:16 AM 8/16/00 -0600, Tony Olekshy wrote:
The proposed omnibus Exceptions RFC uses the following three
rules to guide it while unwinding through the clauses of a
try statement.
Forgive me for eliding your explanation, but I find it a little
opaque
Me too, that's why the subject contains the word "Towards".
Let me advance a model which may be simpler.
1. When an exception is thrown perl looks for the enclosing
try block; if there is none then program death ensues.
2. If there is an enclosing try block perl goes through the
associated catch blocks in order. If the catch criteria
succeed (the exception class matches one in a list, or a
catch expression evaluates to true, or the catch block
catches everything), the catch block is executed.
If the catch block throws an exception, it becomes the
'current' exception (with a link to the previous one),
otherwise there is no longer a current exception.
3. Whether or not a catch block was executed, the finally
block is now executed if there is one. If the finally block
throws an exception, it becomes the 'current' exception
(with a link to the previous one if there was one). At
this point, if there is a current exception, go to step 1.
This seems complete and IMHO easily understood.
Yes, that's much better. Thanks Peter. Here is a slightly
different version which is still slightly more complex, but
which allows me to more clearly illustrate the change I am
proposing.
1. Whenever an exception is thrown it becomes the current
exception (with a link to the previous one if there was one)
and Perl looks for an enclosing try/catch/finally block.
If there is no such enclosing block then program death ensues,
otherwise Perl traps the exception and proceeds as per rule 2.
2. The relevant try block's next associated catch or finally block
is processed according to rules 3 and 4. When there are no
more blocks use rule 5.
3. If the criteria for a catch succeed (an exception was thrown
and either the exception class matches one in a list, or a
catch expression evaluates to true without throwing, or the
catch block catches all exceptions), the catch block is
executed.
If the catch block and its test expression do not throw then
the current exception is cleared. Otherwise, the exception is
trapped and it becomes the 'current' exception (with a link to
the previous one).
Processing continues with rule 2. [But see below --Tony]
4. When a finally block is encountered it is executed.
If the finally block throws an exception it is trapped and it
becomes the 'current' exception (with a link to the previous
one if there was one).
Processing continues with rule 2.
5. After the catch and finally blocks are processed, if there
is a current exception then go to step 1. Otherwise continue
with the statement after the try statement.
My question is: where should processing continue after rule 3?
The version shown above produces the problem I described before:
try { } except { } = catch { }
except { } = catch { }
catch { }
The potential problem is that if the first catch throws, then
the second except will be testing against the $@ from the catch,
not the $@ from the try.
Is this a problem?
Yes, I think it breaks the intuitive model.
I do too, so the question is what to do about it. I propose changing
rule 3 to add the new paragraph marked with **:
3. If the criteria for a catch succeed (an exception was thrown
and either the exception class matches one in a list, or a
catch expression evaluates to true without throwing, or the
catch block catches all exceptions), the catch block is
executed.
If the catch block and its test expression do not throw then
the current exception is cleared. Otherwise, the exception is
trapped and it becomes the 'current' exception (with a link to
the previous one).
** If a catch test succeeds (or throws), then whether or not the
** catch block throws, any succeeding catch blocks up to the next
** finally block are skipped.
Processing continues with rule 2.
This probably means that it should be a syntax error to have any
catch clause follow a non-conditional catch, because such a clause
could never be executed.
throws() outside a try block are caught by the catch
blocks of the next enclosing try block. See above.
Not quite. Throws in a catch block (not a try block per se) still
have to be trapped in order to get to the finally block, if any.
I think you probably meant that, I'm just making it explicit.
The change I described above would get the
Re: Toward an omnibus Perl 6 Exceptions RFC, v0.1.
Peter Scott wrote:
Tony Olekshy wrote:
[snip]And the following output was generated:
Exception
$ = Try::throw('Exception') called from scott2.pm[8].
$ = main::pling('Test') called from scott2.pm[4].
$ = main::bar('Test') called from scott1.pl[1].
$ = main::foo('Test') called from scott1.pl[8].
$ = Try::try(CODE(0xca8830)) called from scott1.pl[9].
$ = Try::try(CODE(0xca2418), 'catch', CODE(0x10b18ac))
called from scott1.pl[8].
If I'm not mistaken, exceptions must bubble up through the call
stack as at the point the exception is thrown, so if we capture
that stack traceback then, we have all the info. Do you still
want the file/line array?
Yes, I want to be able to get at it Ccaller-like. You're just
dumping it.
Ok, but that's just because I was storing it in a string. Instead
of going to all the trouble to format up the string, we can copy
some of those caller fields into an array (one entry per level) of
hashes (one key per value). Like this:
$myException-{stackTrace}-[0]-{file}
$myException-{stackTrace}-[0]-{line}
$myException-{stackTrace}-[0]-{sub}
Yours, c, Tony Olekshy
Re: Towards a reasonable unwinding flow-control semantics.
On Wed, Aug 16, 2000 at 11:49:03AM +0100, Graham Barr wrote:
if any of the catch or finally throws, it is caught by a
try {} block up the stack.
Keep It Simple
What he said.
-Scott
--
Jonathan Scott Duff
[EMAIL PROTECTED]
