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/catc
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 $
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
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 AUTOLOA
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
> >
> > 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 hav
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])
"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
> > }
> >
> &
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
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.
>
>
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.: &g
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.c
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
> >
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 thos
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 som
15 matches
Mail list logo
