Now, every error is guaranteed to be an object. You can call some method
or check some attribute of it to find out if it was an exception. If
you're checking a system() or `` failure, you use it in numerical
context. If you're checking a builtin failure, you use it in string
context
At 09:41 PM 8/28/00 -0600, Tony Olekshy wrote:
I just want the cognitive simplicity of knowing that $@ and every
@@ isa Exception, no matter what.
Why not merge $!, $^E, and $@ into $!, but leave $@ alone too?
That way, none of the existing die/eval code will break without
being modified to
At 01:07 PM 8/29/00 -0600, Tom Christiansen wrote:
Now, every error is guaranteed to be an object. You can call some method
or check some attribute of it to find out if it was an exception. If
you're checking a system() or `` failure, you use it in numerical
context. If you're checking a
At 01:42 AM 8/25/00 -0600, Tony Olekshy wrote:
Peter Scott wrote:
If $@ and $! are merged, then in code like
try {
system_call_that_fails();
more_stuff_that_succeeds();
}
finally {
}
does the finally block
Peter Scott wrote:
Tony Olekshy wrote:
So if open, for example, can set $! without invoking die, then
$! and $@ must not be merged. As I read it, 151 would (as
currently promulgated) not meet my requirement for the unique
nature of a $@-style variable. I don't think overloading
On Thu, 24 Aug 2000 17:57:55 -0700, Peter Scott wrote:
I've read 151 a few times, and I don't understand how it can impact
the implementation of RFC 88 as a module. Please explain.
If $@ and $! are merged, then in code like
try {
system_call_that_fails();
At 06:06 PM 8/24/00 -0600, Tony Olekshy wrote:
In fact, not only would I be pleased and honoured to author the
Perl 6 core Try.pm module, I'm already working on a Perl 5 standard
reference implementation.
That should certainly tell you whether it's doable :-)
Peter, I think we should make this
Peter Scott wrote:
At 06:06 PM 8/24/00 -0600, Tony Olekshy wrote:
In fact, not only would I be pleased and honoured to author the
Perl 6 core Try.pm module, I'm already working on a Perl 5 standard
reference implementation.
Peter, I think we should make this approach more clear in RFC
At 06:48 PM 8/24/00 -0600, Tony Olekshy wrote:
Peter Scott wrote:
At 06:06 PM 8/24/00 -0600, Tony Olekshy wrote:
In fact, not only would I be pleased and honoured to author the
Perl 6 core Try.pm module, I'm already working on a Perl 5 standard
reference implementation.
Peter, I
Graham Barr wrote:
Peter Scott wrote:
Tony Olekshy wrote:
Graham Barr wrote:
I am of the opinion that only a class name should follow
catch. If someone wants to catch based on an expression
they should use
catch {
if (expr) {
}
else {
10 matches
Mail list logo
