Re: try/catch (Was: Re: RFC: Modify open() and opendir() to return handles)
At 11:25 AM 8/4/00 +0200, Johan Vromans wrote:
>[Quoting Hildo Biersma, on August 4 2000, 08:40, in "Re: try/catch (Was: "]
> > Yes, but... this is largely casued by the fact that Java requires you to
> > declare any uncaught parameters on your method specification, and this
> > tends to have a nasty oil-slick effect.
> >
> > If you do it the C++ way, you can say:
> >
> > try {
> > first_sub_that_throws_exceptions();
> > second_sub_that_throws_exceptions();
> > } catch {
> > it went wrong
> > }
>
>How does 'it went wrong' know _which_ of the subs went wrong?
You use this model in the case where you don't care:
try {
sub_doing_database_stuff();
another_sub_doing_database_stuff();
# 32 more of the same
commit();
} catch {
rollback();
};
I am a big fan of http://search.cpan.org/doc/GBARR/Error-0.13/Error.pm.
You also want it for getting out of deeply nested calls to the first thing
that actually cares about it.
I don't want to give up the return-undef-for-error interface of builtins,
though; sorry if I gave that impression. Having both mechanisms a la
Fatal.pm looks attractive. Having structured exception objects so you
don't have to roll your own regexen parsing $@ is also very important...
oops, better save it for the new list...
--
Peter Scott
Pacific Systems Design Technologies
Re: try/catch (Was: Re: RFC: Modify open() and opendir() to return handles)
On Fri, Aug 04, 2000 at 09:10:38AM +0200, Johan Vromans wrote:
> You missed the point.
>
> If you need 6+ lines of code for each elementary error check, this is
> what is going to happen . . .
You're correct, but that's not what I was suggesting. The magic words are
`for each elementary error check.' Many (most?) functions do fine with
a simple error codes returned. But there are some cases where things
go wrong deep inside modules and it's not easy/reasonable/feasible to
return anything meaningful in the error code. For circumstances like
that, a try/catch mechanism is wonderful. It's superior to if (eval)
in expressiveness and flexibility as well.
Those who write all their code like this with try/catch (as Johan
suggested):
> try {
>open file
>while read a record
> process its contents
>finalize file processing
> }
> catch (Exception e) {
>error message: something went wrong
> }
are also probably writing their (pseudo-perl) code like
if ( ! ( $err = open file ) ) {
error message: something went wrong
} else while ( $err = read a line ) {
if ( $err ) {
error message: something went wrong
} else {
process it's contents
}
if ( ! $err ) {
finalize file processing
}
}
Bad code and (in this case) feature abuse are independent of features.
I for one would like a try/catch for the tough cases that need it.
If people want to screw themselves over with abusing it for trivial uses,
that's fine.
PROPOSAL: we should add try/catch to perl, with the caveat that uncaught
exceptions are ignored and an error code returned as per current
functioning.
Or Fri, Aug 04, 2000 at 05:09:13AM -0600, Tom Christiansen wrote:
> >> If you do it the C++ way, you can say:
> >> try {
> >> first_sub_that_throws_exceptions();
> >> second_sub_that_throws_exceptions();
> >> } catch {
> >> it went wrong
> >> }
>
> >How does 'it went wrong' know _which_ of the subs went wrong?
>
As was pointed out elsewhere, the object provided to the catch has
that data. But that's a not really relevant to the clarity, obscurity,
or brevity of code using try/catch. The following working perl code
has recently been removed from some of our tools:
die "Couldn't open database\n" if (!$dhb = open_db("bdconfig", get_dbms("Oracle",
get_host_addr("woody";
This statement appeared in the code twice, widely separated, with
different db/dbms/host but the same error message. Needless to say,
it leaves you pretty clueless as to what went wrong. I've directed
our programmers here that such statements should be rewritten to
my $dbh;
my $host = "woody";
my $dbms = "Oracle";
my $db = "bdconfig";
my $why = "why you want it";
my $addr;
if ( ! $addr = get_host_addr( $host ) ) {
die "Couldn't find host '$host' for $why.\n";
} elsif ( ! $dbms = get_dbms( $dbms, $addr ) ) {
die "Couldn't access DBMS '$dbms' on $host for $why.\n";
} elsif ( ! $dbh = open_db( $db ) ) {
die "Couldn't access $dbms db '$db' on $host for $why.\n";
}
or encapsulated in a function which returns an appropriately
informational error string:
if ( "" ne ( $errstr = opendb( "bdconfig", "woody", "Oracle", \$dbh ) ) ) {
print STDERR $errstr;
}
Both the large code block in the first and the implementation of opendb
(not shown) are pedantic as all hell, but now when the NOC pages me at
3AM, I know where to start looking. I submit that both the above call
to opendb with a string error code and the try/catch version:
try {
$db_handle = opendb "bdconfig", "woody", "Oracle" ;
} catch {
it went wrong
}
are about equally readable, and the try/catch is ultimately more powerful.
Jeez, don't tell me I've just started writing another RFC smiley/2.
--
``Just imagine we are meeting the aliens for the first time. Most
people would just shoot them to see how many points they are worth.''
Simon Cozens in msg <[EMAIL PROTECTED]>
Re: try/catch (Was: Re: RFC: Modify open() and opendir() to return handles)
>> Why would we ever remove a syscall!?!? >I vote for migration to a module. And sysopen and fcntl and waitpid and ioctl
Re: try/catch (Was: Re: RFC: Modify open() and opendir() to return handles)
Tom Christiansen writes: > >Maybe we should address this? If we're keeping syscalls just because a > >possible replacement module is just written wrong, we should fix this. > > Why would we ever remove a syscall!?!? I vote for migration to a module. If you're going to use the long-winded form of socket diddling, you won't mind an extra `use' statement at the top of your program. Especially given that you need to `use' a module to get constants and structs anyway (although this too could be unstupided in the move to perl6). Nat
Re: try/catch (Was: Re: RFC: Modify open() and opendir() to return handles)
>Tom Christiansen wrote: >> >> >> Thats just because IO::Socket is done wrong >> >> >Maybe we should address this? If we're keeping syscalls just because a >> >possible replacement module is just written wrong, we should fix this. >> >> Why would we ever remove a syscall!?!? >Sorry, wrong verbage. I meant "the general purpose socket()". And even >then, no, I'm *not* in favor of removing it. At all. Just maybe changing >it to make it better, faster, more portable. Better and faster are good; you'll note that the socket-related syscalls in Perl are already somewhat different from those of libc, so it's as though diddling them in a perlian way weren't par for this course. So go right ahead. However, I'm not sure what "more portable" has to do with anything. --tom
Re: try/catch (Was: Re: RFC: Modify open() and opendir() to return handles)
Tom Christiansen wrote: > > >> Thats just because IO::Socket is done wrong > > >Maybe we should address this? If we're keeping syscalls just because a > >possible replacement module is just written wrong, we should fix this. > > Why would we ever remove a syscall!?!? Sorry, wrong verbage. I meant "the general purpose socket()". And even then, no, I'm *not* in favor of removing it. At all. Just maybe changing it to make it better, faster, more portable. I'm not sure my idea would accomplish that, hence the disclaimer. My point was just that if IO::Socket was preventing us from possibly doing "really cool stuff", we should fix it. -Nate
Re: try/catch (Was: Re: RFC: Modify open() and opendir() to return handles)
>> Thats just because IO::Socket is done wrong >Maybe we should address this? If we're keeping syscalls just because a >possible replacement module is just written wrong, we should fix this. Why would we ever remove a syscall!?!? --tom
Re: try/catch (Was: Re: RFC: Modify open() and opendir() to return handles)
> Thats just because IO::Socket is done wrong
Maybe we should address this? If we're keeping syscalls just because a
possible replacement module is just written wrong, we should fix this.
I don't like giving up low-level control either, but imagine something
like this:
$port = shift || 2345;# port to connect to
$socket = open $port, IO::Socket, # new portable open()
{ SOCK, PF_INET, SOCK_STREAM, TCP }; # I know "TCP" is wrong
We could then make "socket()" a simple shortcut for this, or just
deprecate it.
Anyways, I'm not claiming this is a *good* idea, but just that if "we
could do it except for the fact that IO::Socket sucks", we should look
at fixing IO::Socket.
-Nate
Re: try/catch (Was: Re: RFC: Modify open() and opendir() to return handles)
On Fri, Aug 04, 2000 at 05:09:13AM -0600, Tom Christiansen wrote: > This is my argument against obsolescing the general-purpose socket() et al. > syscalls in deference to the IO::Socket stuff: Absolutly. A high level API is ok for those who want it. But you should never take away the low-level stuff. > You don't know what blew > up, and lack fine-grained control. (There's also the matter of being > somewhat non-useful for UDP.) Thats just because IO::Socket is done wrong Graham.
Re: try/catch (Was: Re: RFC: Modify open() and opendir() to return handles)
>> If you do it the C++ way, you can say:
>> try {
>> first_sub_that_throws_exceptions();
>> second_sub_that_throws_exceptions();
>> } catch {
>> it went wrong
>> }
>How does 'it went wrong' know _which_ of the subs went wrong?
This is my argument against obsolescing the general-purpose socket() et al.
syscalls in deference to the IO::Socket stuff: You don't know what blew
up, and lack fine-grained control. (There's also the matter of being
somewhat non-useful for UDP.)
--tom
Re: try/catch (Was: Re: RFC: Modify open() and opendir() to return handles)
On Fri, Aug 04, 2000 at 11:25:49AM +0200, Johan Vromans wrote:
> How does 'it went wrong' know _which_ of the subs went wrong? For
> example:
>
> try {
> open(file1);
> open(file2);
> open(file3);
> } catch {
> error("could not open one of the file(s)");
> }
>
> which is not very helpful to the user. And
$@ becomes an object, which can contain information about what went wrong.
Graham.
Re: try/catch (Was: Re: RFC: Modify open() and opendir() to return handles)
[Quoting Hildo Biersma, on August 4 2000, 08:40, in "Re: try/catch (Was: "]
> Yes, but... this is largely casued by the fact that Java requires you to
> declare any uncaught parameters on your method specification, and this
> tends to have a nasty oil-slick effect.
>
> If you do it the C++ way, you can say:
>
> try {
> first_sub_that_throws_exceptions();
> second_sub_that_throws_exceptions();
> } catch {
> it went wrong
> }
How does 'it went wrong' know _which_ of the subs went wrong? For
example:
try {
open(file1);
open(file2);
open(file3);
} catch {
error("could not open one of the file(s)");
}
which is not very helpful to the user. And
try { open(file1) } catch { error("could not open file1"); }
try { open(file2) } catch { error("could not open file2"); }
try { open(file3) } catch { error("could not open file3"); }
is not very helpful to the programmer.
Bottom line: I really appreciate the try/catch mechanism. But let's
learn from C++ and Java how _not_ do do it.
-- Johan
Re: try/catch (Was: Re: RFC: Modify open() and opendir() to return handles)
Johan Vromans wrote:
> You missed the point.
>
> If you need 6+ lines of code for each elementary error check, this is
> what is going to happen (and it _does_ happen in almost every Java
> program I've seen):
>
> try {
>open file
>while read a record
> process its contents
>finalize file processing
> }
> catch (Exception e) {
>error message: something went wrong
> }
>
> All the details about what went wrong, and were, are sacrificed since
> that would have required too much code, over and over again!
Yes, but... this is largely casued by the fact that Java requires you to
declare any uncaught parameters on your method specification, and this
tends to have a nasty oil-slick effect.
If you do it the C++ way, you can say:
try {
first_sub_that_throws_exceptions();
second_sub_that_throws_exceptions();
} catch {
it went wrong
}
without cluttering up the interface of each and every sub.
Having said that, I would prefer the throwing of exceptions by built-in
functions to be optional, and changeable on a scope basis - so some
parts of my code can use an exception-based mechanism, other parts can
do return-value checking. Rather like the way that DBI allows you to
set RaiseError on a database or statement handle and makes you do away
with error-checking for that handle - you just need to catch exceptions
around all uses of that handle.
Hildo
try/catch (Was: Re: RFC: Modify open() and opendir() to return handles)
Steve Simmons <[EMAIL PROTECTED]> writes:
> On Thu, Aug 03, 2000 at 08:54:35PM +0200, Johan Vromans wrote:
> >try {
> > java
> >}
> >catch (Exception e) {
> > think again
> >}
>
> I like this. It's perlish in that it builds off of a well-defined and
> proven mechanism, and it even *looks* perlish.
You missed the point.
If you need 6+ lines of code for each elementary error check, this is
what is going to happen (and it _does_ happen in almost every Java
program I've seen):
try {
open file
while read a record
process its contents
finalize file processing
}
catch (Exception e) {
error message: something went wrong
}
All the details about what went wrong, and were, are sacrificed since
that would have required too much code, over and over again!
-- Johan
Re: RFC: Modify open() and opendir() to return handles
> In fact, you may as well go the whole way and say that all IO is done via > optimised IO objects (ie include sockets etc). IO::File and friends > without the overhead. All of the current open functions simply pass these > objects around. I'll stick this in there, definitely. This is just what I was shooting for. -Nate
Re: RFC: Modify open() and opendir() to return handles
> Are you saying they don't look Perlish now? > > And no, all you guys, I'm not trying to shoot down a monadic, > object-returning open. Please don't assume that. As funny as it sounds, yes. Mind you, they're not really too weird. But compared to how most other functions have turned out working, well, yes. At least a little. > What I *would* like to shoot down is this nutty assumption that > these quasi-constructors be named new(). Choose something in the > proper domain. Is that a new client or a new server? Is it > preconnected or not? etc. > > Avoid new(). Use something descriptive of what's happening. Right, I agree. I used new() in the examples as of *existing* code and modules and how things are done now. You're right, new() is something from C++ that makes Perl look similar on the surface, but ends up being self-defeating in a way because it works so differently in reality. I would say one use of new() that I think is a good one is when you return a $ref that is simply a clone of the class, with no initialized values or special features. But I agree that Apache->request gives you a better idea of what you're getting. -Nate
Re: RFC: Modify open() and opendir() to return handles
On Thu, 3 Aug 2000, Nathan Wiger wrote: > > sysopen() should probably be included in the list as well. > > Good point. > In fact, you may as well go the whole way and say that all IO is done via optimised IO objects (ie include sockets etc). IO::File and friends without the overhead. All of the current open functions simply pass these objects around. -- Tim Jenness JCMT software engineer/Support scientist http://www.jach.hawaii.edu/~timj
Re: RFC: Modify open() and opendir() to return handles
> sysopen() should probably be included in the list as well. Good point. -Nate
Re: RFC: Modify open() and opendir() to return handles
On Thu, Aug 03, 2000 at 08:54:35PM +0200, Johan Vromans wrote:
> Peter Scott <[EMAIL PROTECTED]> writes:
> > If we get a good-looking exception throwing/catching mechanism and
> > syntax, this may not matter.
>try {
> java
>}
>catch (Exception e) {
> think again
>}
I like this. It's perlish in that it builds off of a well-defined and
proven mechanism, and it even *looks* perlish.
Re: RFC: Modify open() and opendir() to return handles
>If we were to agree to make the basic syntax of open() something like:
> $object = open [$filename], [$class];
>There's a lot of cool stuff we could do. In the simplest "mostly looks
>like Perl5" cases, open() can work like shown above. In fact, I'd be
>plenty happy with just this, since it makes open() and opendir() look a
>lot more Perlish to me.
Are you saying they don't look Perlish now?
And no, all you guys, I'm not trying to shoot down a monadic,
object-returning open. Please don't assume that.
>However, if we extended this some more, there's some interesting
>possibilities. Currently, if you want to open an FTP connection, you
>have to do something like this:
> use Net::FTP;
> my $ftp = new Net::FTP ("ftp.perl.com");
> $ftp->login("user", "pass");
>And so on. Same for HTTP connections, etc. However, you could make
>open() extensible, almost like tie() or new()[1] in that it can bind
>objects to classes. So, to open a new FTP connection, maybe Perl6 could
>let you do this:
> $ftp = open "ftp.perl.com/pub", Net::FTP;
>[1] I *know* new() is "just a function", but you know what I mean. :-)
What I *would* like to shoot down is this nutty assumption that
these quasi-constructors be named new(). Choose something in the
proper domain. Is that a new client or a new server? Is it
preconnected or not? etc.
Avoid new(). Use something descriptive of what's happening.
--tom
Re: RFC: Modify open() and opendir() to return handles
Peter Scott <[EMAIL PROTECTED]> writes:
> At 09:01 AM 8/3/00 -0600, Tom Christiansen wrote:
> >Syscalls should use errno. Others may vary.
>
> If we get a good-looking exception throwing/catching mechanism and
> syntax, this may not matter.
try {
java
}
catch (Exception e) {
think again
}
-- Johan
Re: RFC: Modify open() and opendir() to return handles
Bart Lateur <[EMAIL PROTECTED]> writes: > >The open() and opendir() functions would have to be altered to take one > >argument (not two) and return the corresponding file object or undef. > > Actually, open() currently CAN have just one parameter. Does that matter much? After all, we may change things in a non-compatible way, if needed. -- Johan
Re: RFC: Modify open() and opendir() to return handles
On Thu, 3 Aug 2000, Nathan Wiger wrote: > Tom Christiansen wrote: > > > > >On Thu, Aug 03, 2000 at 06:40:30AM -0600, Tom Christiansen wrote: > > >> >Modify open() and opendir() to return filehandle objects > > >> > > >> Here are some things that that will be a problem for: > > > > >I did not see any that would be a problem. > > > > It's not as convenient. > > I'm not sure I understand how it could be less convenient. Maybe the > term "filehandle object" is misleading and smacks of FileHandle. That > wasn't the intent. I propose a new name, "fileobject", that can refer to > something that handles any of these: sysopen() should probably be included in the list as well. -- Tim Jenness JCMT software engineer/Support scientist http://www.jach.hawaii.edu/~timj
Re: RFC: Modify open() and opendir() to return handles
On Thu, 3 Aug 2000, Graham Barr wrote: > On Thu, Aug 03, 2000 at 09:01:44AM -0600, Tom Christiansen wrote: > > >On Thu, Aug 03, 2000 at 08:13:09AM -0600, Tom Christiansen wrote: > > >> No, that's gross. A failed constructor should return undef. See my > > >> later message. > > > > >That has always been my view. But then people say "but why did it fail" > > >and having global variables does not scale well. > > > > Syscalls should use errno. Others may vary. > > It's the other may vary that bothers me. Even the core modules > can't agree, but that is a discussion for the stdlib list. > Isn't there some way to make $! usable when returning from normal subs as well as from syscalls? It seems that $! goes a long way to providing the an error message/error number and just needs a bit of a push to extend it to be more generic. -- Tim Jenness JCMT software engineer/Support scientist http://www.jach.hawaii.edu/~timj
Re: RFC: Modify open() and opendir() to return handles
Tom Christiansen wrote:
>
> >On Thu, Aug 03, 2000 at 06:40:30AM -0600, Tom Christiansen wrote:
> >> >Modify open() and opendir() to return filehandle objects
> >>
> >> Here are some things that that will be a problem for:
>
> >I did not see any that would be a problem.
>
> It's not as convenient.
I'm not sure I understand how it could be less convenient. Maybe the
term "filehandle object" is misleading and smacks of FileHandle. That
wasn't the intent. I propose a new name, "fileobject", that can refer to
something that handles any of these:
$fo1 = open "< $filename";
@file = <$fo1>;
$fo2 = open "| $pipe-to";
print $fo2 "$stuff\n";
$fo3 = open "$pipe-from |";
print while (<$fo3>);
Indeed, this was the intent of the original RFC. I'll revise it to
include this better terminology.
To give a better idea of where I'm going with this, here's a vision I've
come up with. I'm not claiming it's a good vision, but it's a vision.
Tidbits of this were mentioned in the RFC.
If we were to agree to make the basic syntax of open() something like:
$object = open [$filename], [$class];
There's a lot of cool stuff we could do. In the simplest "mostly looks
like Perl5" cases, open() can work like shown above. In fact, I'd be
plenty happy with just this, since it makes open() and opendir() look a
lot more Perlish to me.
However, if we extended this some more, there's some interesting
possibilities. Currently, if you want to open an FTP connection, you
have to do something like this:
use Net::FTP;
my $ftp = new Net::FTP ("ftp.perl.com");
$ftp->login("user", "pass");
And so on. Same for HTTP connections, etc. However, you could make
open() extensible, almost like tie() or new()[1] in that it can bind
objects to classes. So, to open a new FTP connection, maybe Perl6 could
let you do this:
$ftp = open "ftp.perl.com/pub", Net::FTP;
You see how this can be extended. If we wanted "builtin" HTTP file
access, we could say something like:
$http = open "http://www.perl.com/", HTTP::Request,
{ Request => GET };
@doc = <$http>;
Indeed, you could take this further and even say that opendir() was
really just a synonym for:
$dir = open "/my/dir", IO::DirObject; # theoretical
@files = grep !/^\..*/, (<$dir>); # no more readdir!
There's alot of assumptions here. This should not be taken as a
technical document, but a brain dump of creating a portable open().
Again, maybe it's a bad idea, or one that needs massive revision, but
it's an idea I wanted to get out there. There's persistence issues,
object issues, and much more if this was to be considered.
-Nate
[1] I *know* new() is "just a function", but you know what I mean. :-)
Re: RFC: Modify open() and opendir() to return handles
At 09:01 AM 8/3/00 -0600, Tom Christiansen wrote: > >On Thu, Aug 03, 2000 at 08:13:09AM -0600, Tom Christiansen wrote: > >> No, that's gross. A failed constructor should return undef. See my > >> later message. > > >That has always been my view. But then people say "but why did it fail" > >and having global variables does not scale well. > >Syscalls should use errno. Others may vary. If we get a good-looking exception throwing/catching mechanism and syntax, this may not matter. Of course, it has to be optional for core functions to throw exceptions rather than set $!. Still need a global variable for that... -- Peter Scott Pacific Systems Design Technologies
Re: RFC: Modify open() and opendir() to return handles
On Thu, Aug 03, 2000 at 03:19:35PM +0100, Graham Barr wrote:
> I am open to suggestions. Of course one may be move the connect
> out of the constructor. But that leaves the constructor
> being nothin more than a bless.
Here's a modification of my previous evil suggestion:
Have a global (existing everywhere, all the time) "error" thing where
people can put error information. Perl uses it and module authors
could too. This would be similar to $!, only not tied to errno.
$fh = open("file") or die "$ERROR";
$ftp = new Net::FTP->new($host) or die "$ERROR"; # assigned in Net::FTP
just brainstorming,
-Scott
--
Jonathan Scott Duff
[EMAIL PROTECTED]
Re: RFC: Modify open() and opendir() to return handles
On Thu, Aug 03, 2000 at 09:01:44AM -0600, Tom Christiansen wrote: > >On Thu, Aug 03, 2000 at 08:13:09AM -0600, Tom Christiansen wrote: > >> No, that's gross. A failed constructor should return undef. See my > >> later message. > > >That has always been my view. But then people say "but why did it fail" > >and having global variables does not scale well. > > Syscalls should use errno. Others may vary. It's the other may vary that bothers me. Even the core modules can't agree, but that is a discussion for the stdlib list. Graham.
Re: RFC: Modify open() and opendir() to return handles
>On Thu, Aug 03, 2000 at 08:13:09AM -0600, Tom Christiansen wrote: >> No, that's gross. A failed constructor should return undef. See my >> later message. >That has always been my view. But then people say "but why did it fail" >and having global variables does not scale well. Syscalls should use errno. Others may vary. --tom
Re: RFC: Modify open() and opendir() to return handles
On Thu, Aug 03, 2000 at 08:13:09AM -0600, Tom Christiansen wrote: > No, that's gross. A failed constructor should return undef. See my > later message. That has always been my view. But then people say "but why did it fail" and having global variables does not scale well. My comment comes mainly from $ftp = Net::FTP->new($host), may fail for several reasons. I am open to suggestions. Of course one may be move the connect out of the constructor. But that leaves the constructor being nothin more than a bless. Graham.
Re: RFC: Modify open() and opendir() to return handles
>Are you saying that piped opens returning a "filehandle" object makes >testing for failure more troublesome? If so, I have an evil proposal >for you ... Let's make an "error" object (I hate to use that term) >that's *always* false but has some state we can get at. This thing would >encapsulate $!, $?, and friends. Modules (like DBI) could even add state, >but it would still be false. No, that's gross. A failed constructor should return undef. See my later message. --tom
Re: RFC: Modify open() and opendir() to return handles
On Thu, Aug 03, 2000 at 06:57:27AM -0600, Tom Christiansen wrote: > >On Thu, Aug 03, 2000 at 06:40:30AM -0600, Tom Christiansen wrote: > >> >Modify open() and opendir() to return filehandle objects > >> > >> Here are some things that that will be a problem for: > > >I did not see any that would be a problem. > > It's not as convenient. Are you saying that piped opens returning a "filehandle" object makes testing for failure more troublesome? If so, I have an evil proposal for you ... Let's make an "error" object (I hate to use that term) that's *always* false but has some state we can get at. This thing would encapsulate $!, $?, and friends. Modules (like DBI) could even add state, but it would still be false. -Scott -- Jonathan Scott Duff [EMAIL PROTECTED]
Re: RFC: Modify open() and opendir() to return handles
>On Thu, Aug 03, 2000 at 06:40:30AM -0600, Tom Christiansen wrote: >> >Modify open() and opendir() to return filehandle objects >> >> Here are some things that that will be a problem for: >I did not see any that would be a problem. It's not as convenient. --tom
Re: RFC: Modify open() and opendir() to return handles
On Thu, Aug 03, 2000 at 06:40:30AM -0600, Tom Christiansen wrote: > >Modify open() and opendir() to return filehandle objects > > Here are some things that that will be a problem for: I did not see any that would be a problem. Graham.
Re: RFC: Modify open() and opendir() to return handles
>Modify open() and opendir() to return filehandle objects
Here are some things that that will be a problem for:
open(SESAME, "| output-pipe-command") # set up an output filter
open(SESAME, "input-pipe-command |") # set up an input filter
open SPOOLER, "| cat -v | lpr -h 2>/dev/null"
open SPOOLER, "|-", "lpr", "-h"
open(STDOUT, "| $pager")or die "can't fork a pager: $!";
open STATUS, "netstat -an 2>/dev/null |"
open STATUS, "-|", "netstat", "-an"
open(PROG_TO_READ_AND_WRITE, "| some program |") # WRONG!
open(OOF, "echo $arg|") # Insecure due to tainted $arg, but...
open(OOF,"-|")# Considered OK: see below for taint
open(OOF,"-|", 'echo', $arg # Same as previous, likewise OKish.
open(FROMKID, "-|") or exec("myprog", "arg1", "arg2")
open(FROMKID, "-|", "myprog", "arg1", "arg2");
open(MAIL, '|/usr/lib/sendmail -t') or die "cannot fork sendmail: $!";
open(OUTPUT, '| sort -rn | lpr -p') # pipe to sort and lpr
open(NETSTAT, "netstat -rn |")
open(PRINTER, "| lpr -Plp1")or die "can't fork: $!";
open(NET, "netstat -i -n |")or die "can't fork: $!";
open(PRINTER, "|-", "lpr -Plp1")or die "can't fork: $!";
open(NET, "-|", "netstat -i -n")or die "can't fork: $!";
open(PRINTER, "|-", "lpr", "-Plp1")or die "can't fork: $!";
open(NET, "-|", "netstat", "-i", "-n") or die "can't fork: $!";
open FH,"| tr 'a-z' 'A-Z'";# to shell command
open FH, "|-",'tr', 'a-z', 'A-Z'; # to bare command
open FH, "|-" or exec 'tr', 'a-z', 'A-Z' or die; # to child
open FH, "cat-n 'file' |"; # from shell command
open FH, "-|",'cat', '-n', 'file';# from bare command
open FH, "-|" or exec 'cat', '-n', 'file' or die; # from child
Note than N-arg open remains pre-documented.
--tom
Re: RFC: Modify open() and opendir() to return handles
>Actually, open() currently CAN have just one parameter. What it does, is >use a filehandle and a scalar variable with the same name, so >Nope. Get rid of it! (p.s. Has anybody ever actually used this feature, Yes, of course. That isn't an argument for its persistence, however. --tom
Re: RFC: Modify open() and opendir() to return handles
On Wed, 02 Aug 2000 20:58:51 -0700, Nathan Wiger wrote: >=head1 IMPLEMENTATION > >The open() and opendir() functions would have to be altered to take one >argument (not two) and return the corresponding file object or undef. Actually, open() currently CAN have just one parameter. What it does, is use a filehandle and a scalar variable with the same name, so open FH is the same as open FH, $FH; But that is conceptually tied so closely to typeglobs (filehandle and scalar in same typeglob), that it may just as well become obsolete. I wonder if it works with lexical variables anyway. my $FILE = $0; open FILE or die "Error: $!"; print ; --> Use of uninitialized value in open at test.pl line 3. Error: at test.pl line 3. Nope. Get rid of it! (p.s. Has anybody ever actually used this feature, apart for Perl Golf?) -- Bart.
