Re: [Gnu-arch-users] Nit

[Andrew Suffield]

On Mon, Oct 20, 2003 at 06:07:36PM -0700, Dustin Sallings wrote:
> 
> On Monday, Oct 20, 2003, at 15:16 US/Pacific, Andrew Suffield wrote:
> 
> >I can say with a fair amount of certainty that of all the C code I've
> >written, I've never ignored the result of open/read/write, or any
> >other syscall that I cared about. printf can't fail in any way that I
> >care about and can recover from.
> 
>       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.

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.

> It can 
> fail like any other write call.  Should your program continue running 
> and writing to a file when each write is failing just because you ran 
> out of disk space somewhere?

Yes, absolutely. ENOSPC is a temporary error which can be fixed, so
the program can continue writing its output and unload the buffer when
there is space again.

>       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.

> >>    1) It can't be applied in general (you have to specifically list
> >>    every function you'll ever want to throw an exception).
> >
> >This is false, because the set of syscall primitives in perl is very
> >small. It is easy to list them all.
> 
>       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.

I can even think of a few ways to generate it on the fly, although
they would be a little slow. I'd probably create a sub-module for
Fatal with a precompiled list.

> >>    3) If 0 or undef is a valid result for a function, it can't be
> >>    wrapped with Fatal.
> >
> >Only system() returns in this fashion, and that is considered an
> >aberration. Perl functions should not, in general, do this. A direct
> >equivalent would be "If throwing an exception is the normal way to
> >return a result from a function, ...". It's also trivial to wrap them
> >yourself; Fatal just saves a dozen characters.
> 
>       To say that 0 should not ever be a valid result from a function 
>       seems a little odd.

Definitely not a perl programmer.

> >>    5) If 0 is a valid, but undef is an invalid result from a function,
> >>Fatal cannot be used.
> >
> >I don't think I've ever seen a function return with a convention that
> >stupid. It'd be like "Even numbers are success, odd numbers are 
> >errors".
> 
>       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.

> >It would be rather less pleasent if the primitives already threw
> >exceptions and you wanted the current behaviour - you'd have to trap
> >the exception, store it someplace, and generate a suitable return
> >code, which would be needlessly slow and clumsy.
> 
>       My experience has shown that the number of times I want to ignore a 
> particular invocation of a function have been few enough that I don't 
> mind a stray try/catch.  I typically want to group a bunch of things 
> together, do them as all or nothing and handle the error of ``all of 
> this stuff'' separately, if at all.

I regularly want both, and I expect that anybody who uses perl
seriously would want the same. Perl provides both.

> >If anybody really wanted the primitives to behave in the manner you
> >describe, they could easily write wrappers for every single one of
> >them and put them in a module. It would be a _small_ module.
> >
> >You have absolutely no cause for complaint about library modules which
> >don't throw exceptions, because that happens in every language,
> >especially java; it's up to the library author to decide whether to
> >use exceptions or not.
> 
>       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.

-- 
  .''`.  ** Debian GNU/Linux ** | Andrew Suffield
 : :' :  http://www.debian.org/ |
 `. `'                          |
   `-             -><-          |

signature.asc
Description: Digital signature