On Fri, Apr 15, 2005 at 03:22:48PM -0700, Michael G Schwern wrote:
: On Fri, Apr 15, 2005 at 11:52:38PM +0200, Juerd wrote:
: > > becomes an unverifiable operation. You have to use chdir() if you want to
: > > error check and $CWD is reduced to a "scripting" feature.
: >
: > Well, after failure it can be cwd() but false without breaking any real
: > code, because normally, you'd never if (cwd) { ... }, simply because
: > there's ALWAYS a cwd. If this is done, the thing returned by the STORE
: > can still be an lvalue and thus be properly reffed.
:
: Good idea!
But if cwd() or chdir() doesn't fail(), you probably won't get any
information on *why* the chdir failed in either the return value or $!.
That could be construed as antisocial.
In general I think "but" should be reserved for situations where the
original interface designer showed sufficient lack of imagination to
warrant such workarounds. That is how I treated all the RFCs that
made use of "but" for built-in functionality, and I haven't seen any
good reasons to alter my views on that. About the closest we get
to it is that "interesting values of undef" can be thought of as new
Exception(...) but undefined, or some such. But even that is usually
hidden behind the fail() predicate, and the undef role is probably
composed into exceptions in the first place. Or maybe it's the
other way around.
Larry
