From: jimka
Subject: open raises an error
Date: 
Message-ID: <ad43c384-4c42-41c4-935c-a8296a9093ff@g1g2000yqh.googlegroups.com>
can someone tell me what the specified behavior for the OPEN function
is, if it tries to open a file but fails.  I know you can specify :if-
exists or :if-does-not-exist, but I cannot find in the CLHS what
should happen in the case of permission denied, or director-does-not-
exist etc.  It seems to specify when OPEN is allowed to raise an error
but it does not include these common exceptional cases.

Both allegro and sbcl raise an error (which seems reasonable) but seem
to violate the spec.
Maybe there is somewhere else in the spec that explains this which i
am unable to find?

-jim

From: Thomas A. Russ
Subject: Re: open raises an error
Date: 
Message-ID: <ymir5xrn9vr.fsf@blackcat.isi.edu>
jimka <·····@rdrop.com> writes:

> can someone tell me what the specified behavior for the OPEN function
> is, if it tries to open a file but fails.

I would expect that it would signal an error of type FILE-ERROR.

From the specification page for FILE-ERROR:

  "The type file-error consists of error conditions that occur during an
  attempt to open or close a file, or during some low-level transactions
  with a file system."
 
>  know you can specify :if-
> exists or :if-does-not-exist, but I cannot find in the CLHS what
> should happen in the case of permission denied, or director-does-not-
> exist etc.  It seems to specify when OPEN is allowed to raise an error
> but it does not include these common exceptional cases.

Well, I don't think that the listing of exceptional cases is necessarily
exhaustive in the function description.  Sometimes the information comes
from a different part of the specification.  But I suppose one of the
regulars from the standards committee could elaborate.

But perhaps there should have been a more blanket specification.  I
think that in general, exceptions can be signaled by conforming
implementations, without specific notation in the specification,
whenever some exceptional situation occurs.  Not just when it is
specifically noted.

> Both allegro and sbcl raise an error (which seems reasonable) but seem
> to violate the spec.
> Maybe there is somewhere else in the spec that explains this which i
> am unable to find?

There is the reference in the description of FILE-ERROR.


-- 
Thomas A. Russ,  USC/Information Sciences Institute
From: Pascal J. Bourguignon
Subject: Re: open raises an error
Date: 
Message-ID: <87my8f4xps.fsf@galatea.local>
jimka <·····@rdrop.com> writes:

> can someone tell me what the specified behavior for the OPEN function
> is, if it tries to open a file but fails.  I know you can specify :if-
> exists or :if-does-not-exist, but I cannot find in the CLHS what
> should happen in the case of permission denied, or director-does-not-
> exist etc.  It seems to specify when OPEN is allowed to raise an error
> but it does not include these common exceptional cases.
>
> Both allegro and sbcl raise an error (which seems reasonable) but seem
> to violate the spec.

Incredible isn't it?  And there's even worse, there are even operators
that absolutely ALL implementations implement contrarily to the
specifications (have a look at PROG2).


> Maybe there is somewhere else in the spec that explains this which i
> am unable to find?

Indeed, this is one of the problem of Common Lisp: the conditions that
are signaled are underspecified in general.  Therefore they're hardly
usable (for automatic recovery).  Notably, they're often entirely
implementation dependant.

You could write a "standard" conditions portability library, that
would wrap all the Common Lisp functions, and handle all the
conditions signaled by the various implementations, forwarding them as
"standardized" conditions that you would have to define.  Of course,
in some implementations you couldn't get much information about a give
condition (it may even never be signaled), while some other
implementations are more 'verbose'.  So your "standardized" conditions
would actually have a lot of optional slots...


User defined libraries and program can fully specify their conditions,
which is helpful when you want to implement automatic condition
handling.

-- 
__Pascal Bourguignon__