Subject: [clisp-list] Can CLOSE signal an error? (was: CHARSET questions & early vs late error signaling)

From: "Hoehle, Joerg-Cyril" <[email-masked]>
Date: Tue Aug 20 04:20:03 2002

Sam Steingold wrote:
>actually this behavior is mandated by the ANSI CL spec: CLOSE cannot
>signal an error.

I cannot believe so, i.e., I suspect misinterpretation of the CLHS. But I'm not firm at standard interpretation.

I believe you read:
http://www.lispworks.com/reference/HyperSpec/Body/f_close.htm#close
"Exceptional Situations: None."

But similar text is there for FINISH/FORCE/CLEAR-OUTPUT:
http://www.lispworks.com/reference/HyperSpec/Body/f_finish.htm#force-output
"Exceptional Situations:
Should signal an error of type type-error if output-stream is not a stream designator."

-- That's all it says.
Yet we all know that forcing a buffer to the file systems can result in I/O errors (like any read or write can). So would that mean that CLHS mandates such I/O errors be explicitly ignored?! I'm sure it's not the case. It cannot be the case (what a sin against reliability!).

Neither is an I/O error is mentioned under exceptional situations for WRITE-SEQUENCE et al.

I believe "exceptional situations" is not an exhaustive list. Kent M Pitman said something on this topic on cll in July this year.

I'm sure the CLHS does *not* mandate that the application/programmer never sees any error generated by the OS calls underlying WRITE, FORCE-OUTPUT or CLOSE.
Or CLISP is inconsistent again: CLOSE shall not signal errors, while WRITE could?

Kent Pitman said:
http://groups.google.com/groups?hl=en&lr=&ie=UTF-8&threadm=sfw65zkaitb.fsf%40shell01.TheWorld.com&rnum=1&prev=/groups%3Fas_q%3Dexceptional%2Bsituations%26num%3D20%26as_scoring%3Dr%26hl%3Den%26ie%3DISO-8859-1%26btnG%3DGoogle%2BSearch%26as_epq%3D%26as_oq%3D%26as_eq%3D%26as_ugroup%3Dcomp.lang.lisp%26as_usubject%3D%26as_uauthors%3Dpitman%26as_umsgid%3D%26lr%3D%26as_drrb%3Dq%26as_qdr%3D%26as_mind%3D12%26as_minm%3D1%26as_miny%3D2002%26as_maxd%3D20%26as_maxm%3D8%26as_maxy%3D2002%26safe%3Dimages
>So since you can neither conclude things from the presence nor the absence
>of text in the Exceptional Situations section, you are indeed reading more
>into it than is intended, but you are doing so in part, I'm betting, because
>you misunderstand an "Exceptional Situation" to be a requirement or permission
>to signal or not signal, and it isn't that at all.

I believe this could describe why Sam (IMHO wrongly) states "CLOSE cannot signal an error".
Kent said:
>The absence of exceptional situations does not mean "this function has no
>exceptional situations".  It means "no text was put here".  

Regards,
	Jorg Hohle.

---

From: Sam Steingold <[email-masked]>
Date: Tue Aug 20 07:26:03 2002

Okay, suppose I buy that.
What behavior would you expect from
        (CLOSE *TERMINAL-IO*) ==> ?
An error, right?
What about
        (CLOSE *STANDARD-OUTPUT*) ==> ?
*STANDARD-OUTPUT* is #<IO SYNONYM-STREAM *TERMINAL-IO*>.
closing of SYNONYM-STREAMs is non-recursive, so this does not affect
*TERMINAL-IO*, but it certainly makes further i/o impossible.
Your logic dictates that CLOSE must check all streams for being the
value of *STANDARD-OUTPUT*, *STANDARD-INPUT*, *QUERY-IO* &c &c &c &c.
Isn't it too much?

Let us step back and ask: what problem are we trying to solve here?
I seem to recall vaguely that the problem was that the closed terminal
stream was causing a crash - right?
In that case, we should build --with-debug and see why it was closed in
the first place.

-- 
Sam Steingold (http://www.podval.org/~sds) running RedHat7.3 GNU/Linux
<http://www.camera.org> <http://www.iris.org.il> <http://www.memri.org/>
<http://www.mideasttruth.com/> <http://www.palestine-central.com/links.html>
Don't ascribe to malice what can be adequately explained by stupidity.