Re: [Gnu-arch-users] Nit

[Dustin Sallings]

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

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

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

> >         2) Because of #1, the process is inconsistent, therefore unreliable
> > (you miss one, and your application will mysteriously fail).
>
> Therefore irrelevant.

	You certainly have the opportunity to miss one if you have to know 
them and list them all for it to be successful.

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

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

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

> 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).  
Libraries that try to have errors handled with return codes are not 
written in java (they just happen to compile there).

--
Dustin Sallings