Re: On the case for exception-based error handling.
At 10:20 AM 8/27/00 -0400, Bennett Todd wrote:
>I'd usually rather just say
>
> my $fh = open $filename;
>
>and be done with it, but then I'd always "use Fatal qw(:all);". But
>if I'd done such a "use Fatal", and then wanted to catch one, I sure
>hope I wouldn't have such a rabid try/catch bru-ha-ha inflicted on
>me; couldn't I just say
>
> my $fh = eval { open $filename } or whatever ...;
>
>die/eval works really sweetly; I haven't figured out why people
>want to replace eval { BLOCK } with try/catch. If you want more
>structured data in the exception, make $! an arbitrary complex
>object that stringifies to the text message.
We're proposing exactly that. RFC 88 refers to $@ as that variable; RFC
151 proposes merging $@ into $!. And eval BLOCK should work exactly the
same way in Perl 6 as it does now, so you will indeed be able to do what
you propose. (This is my position and RFC 88's position, but there are
disagreements.)
(Nearly) everrrybuddy heppy :-)
--
Peter Scott
Pacific Systems Design Technologies
Re: On the case for exception-based error handling.
2000-08-22-15:13:23 Peter Scott:
> I too would rather say
>
> my $fh = open $filename or die "Couldn't copy source: $!"
>
> than
>
> my $fh; try { $fh = open $filename } catch { die "Couldn't copy
> source: ", $@->syserr }
I'd usually rather just say
my $fh = open $filename;
and be done with it, but then I'd always "use Fatal qw(:all);". But
if I'd done such a "use Fatal", and then wanted to catch one, I sure
hope I wouldn't have such a rabid try/catch bru-ha-ha inflicted on
me; couldn't I just say
my $fh = eval { open $filename } or whatever ...;
die/eval works really sweetly; I haven't figured out why people
want to replace eval { BLOCK } with try/catch. If you want more
structured data in the exception, make $! an arbitrary complex
object that stringifies to the text message.
> Module authors should also be able to take advantage of Fatal.pm.
> "use Fatal" should set something that can be checked by any
> programmer (heck, that doesn't even have to be restricted to
> module authors; the creator of an insanely large program might do
> it). The programmer can use this to decide whether to throw an
> exception or return. [Bennett, this impacts RFC 70 in IMHO a good
> way; you may consider expanding its scope to be not just binding
> on the core, but advisory for everything else. Perhaps suggest an
> interface whereby user code can see what the setting is.]
I beat you to it. While RFC 70 was intended to just request that it
be possible to finish Fatal.pm so it works as intended and desired,
it does mention:
If [the finishing-up of Fatal.pm, after fixing the busted core]
were a success, then the requested category could also be posted
into a testable variable, allowing module authors who wished to
to automatically support this functionality as well.
:-)
-Bennett
PGP signature
Re: error handling and syntax extension
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. Please take this to the -errors sublist. Thanks... K. -- Kirrily Robert -- <[EMAIL PROTECTED]> -- http://netizen.com.au/ Open Source development, consulting and solutions Level 10, 500 Collins St, Melbourne VIC 3000 Phone: +61 3 9614 0949 Fax: +61 3 9614 0948 Mobile: +61 410 664 994
Re: error handling and syntax extension
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]
error handling and syntax extension
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. This would be similar to the RFC18 immediate subroutines, as it would be another way to change the language of the remainder of the current program. A way to describe syntax errors within the exception object would need to be defined, that looks like the major block.
Re: Error handling
> >
> > Timeouts, shouldn't be reliant on UNIX. (Although I dont think they
should
> > be in the language eigther. A system is easily developed using threads.
> > something which I hope to develop when perl6 is ready...)
> >
>
> I don't understand this paragraph.
As it stands, if you want to have a timeout on a peice of
code/function/whatever.. you need to use eval, $SIG{ALRM}and alarm()
Unfortuantely alarm() doesnt work on windows (and probobally any other
non-posix os)...
I just think that if Perl6 means one thing, and it effects only one great
change. TRUE platform independance should be it
Java is the success it is because of it. And lets face it, we're all here
because we like Perl more, so to paraphrase Larry "Use the stuff that rocks,
and not the stuff that sucks"...
Re: Error handling
On Tue, 08 Aug 2000, Brad hughes wrote: > > Why not? Throw and catch are familiar to programmers. > > Not all programmers. > Oops, correct. My mistake. Even more reason not to introduce yet another lexicon. -- Bryan C. Warnock ([EMAIL PROTECTED])
Re: Error handling
"Bryan C. Warnock" wrote:
> On Tue, 08 Aug 2000, Peter Bevan wrote:
[...]
> > Error handling should be supported by it's own keyword
> i.e.: >
> > trap {
> > #CODE
> > }
> > release (error) {
> > # ERROR
> > }
> >
> > (just because I didn't want to steal throw and catch)
>
> Why not? Throw and catch are familiar to programmers.
Not all programmers.
> Creating brand new vocabulary may potentially hinder a Foo->Perl and
> Perl->Foo transition for someone. Use what people know.
eval {
#CODE
}
else {
#ERROR
}
Re: Error handling
Thus it was written in the epistle of Peter Scott, > > I do not want a language designed by a committee, or even a > democracy. This is art, not politics. Preach on, brother! Ted -- Ted Ashton ([EMAIL PROTECTED]), Info Sys, Southern Adventist University == The solution of problems is one of the lowest forms of mathematical research, ... yet its educational value cannot be overestimated. It is the ladder by which the mind ascends into higher fields of original research and investigation. Many dormant minds have been aroused into activity through the mastery of a single problem. -- Finkel, Benjamin Franklin == Deep thoughts to be found at http://www.southern.edu/~ashted
Re: Error handling
At 06:45 PM 8/8/00 -0400, Bryan C. Warnock wrote:
>I think that Perl survived its first through fifth births because the
>idioms it chose to implement were familiar.
>
>One could conceivably create a semantically pure language with
>no platform or OS dependencies, but then no one would use it.
>
>Creating new idioms is fine. I'm all for it. If you can do it in a
>language, why not do it? What's wrong with map{} in a void context?
>;-)
>
>Be careful destroying old idioms out of spite, or just because you've
>created a new one.
>
>In most cases, you haven't created a replacement, but a substitute.
>There's a difference.
FWIW, as far as I'm concerned, these lists are just an extension of the
creative mind of Larry (and whoever he chooses to form a cabal with :-)
) Go hog wild; carve up the language as much as you want; brainstorm, get
wacky. Ultimately every idea will go through Larry & Co and I trust
his/their judgement to use whatever looks good and ditch the rest, however
popular.
I do not want a language designed by a committee, or even a
democracy. This is art, not politics.
--
Peter Scott
Pacific Systems Design Technologies
Re: Error handling
On Tue, 08 Aug 2000, Peter Bevan wrote:
> However, with the birth of the new Perl, I think it is time to bury those
> ideoms in the language and
> start inventing new ones..
>
Two words: "New Coke"
I think that Perl survived its first through fifth births because the
idioms it chose to implement were familiar.
One could conceivably create a semantically pure language with
no platform or OS dependencies, but then no one would use it.
Creating new idioms is fine. I'm all for it. If you can do it in a
language, why not do it? What's wrong with map{} in a void context?
;-)
Be careful destroying old idioms out of spite, or just because you've
created a new one.
In most cases, you haven't created a replacement, but a substitute.
There's a difference.
> Error handling should be supported by it's own keyword
i.e.: >
> trap {
> #CODE
> }
> release (error) {
> # ERROR
> }
>
> (just because I didn't want to steal throw and catch)
Why not? Throw and catch are familiar to programmers.
Creating brand new vocabulary may potentially hinder a Foo->Perl and
Perl->Foo transition for someone. Use what people know.
(Today, one of my coworkers couldn't understand why 'next;' wasn't
working in a C++ while loop.)
>
> Timeouts, shouldn't be reliant on UNIX. (Although I dont think they should
> be in the language eigther. A system is easily developed using threads.
> something which I hope to develop when perl6 is ready...)
>
I don't understand this paragraph.
--
Bryan C. Warnock
([EMAIL PROTECTED])
Re: Error handling
please move this thread to flow as we have the error RFC posted there. thanx, uri -- Uri Guttman - [EMAIL PROTECTED] -- http://www.sysarch.com SYStems ARCHitecture, Software Engineering, Perl, Internet, UNIX Consulting The Perl Books Page --- http://www.sysarch.com/cgi-bin/perl_books The Best Search Engine on the Net -- http://www.northernlight.com
RE: Error handling
At 10:33 AM 8/8/00 -0500, Brust, Corwin wrote:
>From: Peter Bevan [mailto:[EMAIL PROTECTED]]
>
>
> >Error handling should be supported by it's own keyword i.e.:
> >
> >trap {
> > #CODE
> >}
> >release (error) {
> > # ERROR
> >}
>
This is being hashed out on per6-language-flow right now...
--
Peter Scott
Pacific Systems Design Technologies
RE: Error handling
From: Peter Bevan [mailto:[EMAIL PROTECTED]]
>Error handling should be supported by it's own keyword i.e.:
>
>trap {
> #CODE
>}
>release (error) {
> # ERROR
>}
I think this is touched on by RFC# 3 wherein I ask for user definable error
messages. With those one could presumably set an error or warning's
handler (I suggested a callback interface) to undef to ignore that error or
warning.
What I was suggesting was somthing like:
$PERL_CORE{DIE} => undef;
die 'you can't kill me!'; # is ignored
{
$PERL_CORE{DIE} = { fatal => 0 }
die 'just a warning!'; # just produces a warning
}
die 'I\'m not dead yet!'; # back to ignoring die
$PERL_CORE{DIE} = { fatal => 'tiz true' };
die 'OK, OK, already, I'm dead'; # terminates program using CORE::die
# and prints "OK, OK, already, I'm dead"
$PERL_CORE{DIE} = { fatal => 1, sub { CORE::die q(Bring out yer dead!) } }
die 'OK, OK, already, I'm dead'; # terminates program using
# $PERL_CORE{DIE}->{handler}->()
# so it prints "Bring out yer dead!"
Not knowing much about perl internals, my propostal is quite vague, but am I
correct in assuming that what your asking for is the same, namely executing
a custom code block when a known error (and perhaps warning) is encoutered
at runtime?
As for implementation (ie:
$PERL_CORE{SOME_ERROR}
vs
trap { ... } release () { ... }
) I'm not opposed to either, but I think a few others should weigh in, then
maybe an RFC. Also I kind of like
catch / release
for amusement value.
-Corwin
Error handling
I started writing this mail by asking:
>Does anyone else agree that perl should have support for (but not
forcefully) error handling...
>maybe a little like Java's??
>I know that sort of thing can be acheived with eval(), but surely
Which is as far as I got, because something new has occured to me...
We all know (and most of us love) the timeless Perl ideoms, such as using
eval to trap die's etc
However, with the birth of the new Perl, I think it is time to bury those
ideoms in the language and
start inventing new ones..
Error handling should be supported by it's own keyword i.e.:
trap {
#CODE
}
release (error) {
# ERROR
}
(just because I didn't want to steal throw and catch)
Timeouts, shouldn't be reliant on UNIX. (Although I dont think they should
be in the language eigther. A system is easily developed using threads.
something which I hope to develop when perl6 is ready...)
The list could go on forever... and although I accept that most of them
should stay as they are, there is a little core that should become part of
the language
What do you all think
