Re: [Gnu-arch-users] Nit

[Dustin Sallings]

On Tuesday, Oct 21, 2003, at 10:52 US/Pacific, Andrew Suffield wrote:

> >         I'm not talking about error recovery, I'm talking about error
> > trapping.  printf() is a write() call as far as I'm concerned.
>
> I disagree with this equivalence very strongly, which is why printf()
> is one of the few calls which I don't bother to check the result
> of. fprintf(stderr, ...) is another.

        Are you saying you make assumptions about particular file descriptors?

dustin2wti:/Volumes/Untitled 555% ./test > test.out
printf: No space left on device
dustin2wti:/Volumes/Untitled 556% echo $?
2

	The concept of caring enough about something to write it, but not 
enough to actually see that it gets done is a little foreign to me.  
printf is performing IO.  IO has a lot of potential for failure, and 
that should be considered.

> These are special because they are stdio.
>
> In the case of a permanent error, the stream will be marked as closed
> and further printf() calls will return rapidly, probably without
> calling write() at all.
>
> In the case of a temporary error, the data will go into the buffer and
> be unloaded later when the output stream is ready again.
>
> In neither of these cases do I want to waste space in my program with
> handling of these errors, because they already do exactly what I want
> them to do.
>
> In neither of these cases do I want my program to abort.
>
> I have never even encountered a program where this was not true, let
> alone written one.

	Are you familiar with signal 13?  That's what your application 
receives when its standard out goes to a pipe and the pipe closes.  The 
default behavior is to have your program abort when it's unable to 
produce any more output.

	Are you suggesting that it's OK to abort if you're no longer able to 
write output to a consumer process, but not OK to abort if you're no 
longer able to write output to a filesystem?

> >         I think this is a good example of exceptions making it easier to
> > 	write more reliable software.  If printf() would just fail if it 
> > couldn't
> > do what you asked it to do, your code would stop running when you ran 
> > out
> > of disk space (unless you trapped it and wanted to do something
> > different).
>
> It would be really amazingly stupid for your program to fail just
> because somebody closed stdin. I can't believe you are seriously
> suggesting that. This would be considered a serious bug in pretty much
> any unix program.

	I was referring to stdout, but do you consider the same true for 
stdin?  If the program wants to read from stdin, and there is no stdin, 
should the program continue to try to read from stdin?  If so, how is 
this different?

> >         But it doesn't, and it's not automatic, and I don't know the list,
> >         and I won't necessarily know when they add one, etc...
>
> Then you're not a perl programmer. QED.
>
> Ask a perl programmer to write it for you.

	Well that sounds like an intelligent solution.  I'm talking about ways 
to make it easier for everyone to write reliable software and you're 
suggesting someone else should do who knows all the secrets of a 
particular language.  Got it.

> >         To say that 0 should not ever be a valid result from a function
> >         seems a little odd.
>
> Definitely not a perl programmer.

	Does perl not have non-blocking IO, or are read and syswrite just 
guaranteed to never return 0 under any circumstances?  Actually, let's 
look in the docs:

dustin2wti:/Volumes/Untitled 566% perldoc -f read
       read FILEHANDLE,SCALAR,LENGTH,OFFSET

       read FILEHANDLE,SCALAR,LENGTH
               Attempts to read LENGTH bytes of data into vari-
               able SCALAR from the specified FILEHANDLE.
               Returns the number of bytes actually read, `0' at
               end of file, or undef if there was an error.
               SCALAR will be grown or shrunk to the length actu-
               ally read.  An OFFSET may be specified to place
               the read data at some other place than the begin-
               ning of the string.  This call is actually imple-
               mented in terms of stdio's fread(3) call.  To get
               a true read(2) system call, see `sysread'.

	Here, it says undef is returned for error, and 0 is a valid result 
saying that you've reached EOF.  Fatal does not distinguish.

> >         I didn't say that.  Consider mktime.  It may return either 0 or
> > 	undef. 0 is success, undef is an error.  Both will cause an 
> > exception to
> >  be thrown from Fatal.
>
> That's a C function. Not a perl one.
>
> The perl equivalent is Time::Local::timegm. It's not a core function,
> so it's not relevant to Fatal. Particularly since it already throws an
> exception on error.

        I got it from my perldoc:

       mktime  Convert date/time info to a calendar time.

               Synopsis:

                       mktime(sec, min, hour, mday, mon, year, wday = 
0, yday = 0, isdst = 0)

	It may not be the one of many tools you use for constructing epoch 
time, but it's the one that I've known of the longest.  If it's not 
appropriate, they should pull it.

> >         Especially java?  All of the core java stuff throws exceptions when
> > there's an error (I'm sure there's at least one exception somewhere).
>
> Did you *read* what I said? If I had meant core stuff, I would have
> said "core stuff". I clearly said "library modules".
>
> There is no end of class libraries for java which have poor or no
> error handling mechanisms, and there's a whole bunch more (mostly JNI
> stuff) that use errno-like mechanisms instead of exceptions.

	Yeah, I did, and I was trying to make sense of it.  You said this is a 
problem especially in java.  Java has conventions for doing things that 
experienced java developers adopt (i.e. the kind who make libraries and 
stuff).  The java way is to use exceptions.  Nobody who is remotely 
used to using java is going to expect anything else.

	If there is no end of class libraries that do this, can you provide a 
pointer to a couple that are actually used?

--
Dustin Sallings