Re: [Gnu-arch-users] Nit

[Andrew Suffield]

On Mon, Oct 20, 2003 at 01:39:03PM -0700, Dustin Sallings wrote:
> 
> On Monday, Oct 20, 2003, at 11:57 US/Pacific, Andrew Suffield wrote:
> 
> >>    In languages that do not raise exceptions normally upon error, you
> >>have to check the results of each of those calls to make sure they're
> >>successful, as well as figuring out something to do when they're not.
> >>These are two things that put extra burden on a programmer that is
> >>often skipped because it's additional work that is not directly 
> >>related
> >>to the logic that the programmer wants expressed.
> >
> >I have never written code like this. Anybody who does is a
> >moron. Morons cannot be helped except with a shotgun, and should
> >definitely not be allowed to write code.
> 
>       Unless you've only programmed in languages like Eiffel (where 
> exceptions are always present and return values cannot be ignored), I 
> don't think I can believe you when you say that you've never ignored 
> the return value of a function that could have indicated an error of 
> some sort (printf, etc...).

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 can't see any way that somebody who _doesn't_ follow this practice
has any business writing C code.

> >>Fatal for now, I think that's a fairly stupid hack) in order to remove
> >  ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
> >
> >That says it all, really. It does precisely what you want with no
> >appreciable source code or runtime overhead, while making the other
> >path available to people that want it with similar lack of overhead,
> >and you call it a "stupid hack".
> >
> >I think your value function is broken, or at least contrived.
> 
>       It does not do precisely what I want.  I want to code for the One 
>       True Path and have it be executed fully when all operations succeed.  I 
> will optionally add handling for specific error conditions if I feel 
> there's an appropriate way to handle them, but I will know that the 
> application will, by default, stop when the first thing I told it to do 
> cannot be done.
> 
>       Fatal gives you the option to basically interposition a wrapper 
>       around a function so it can throw an exception if the result of the 
> underlying returns a value that would be evaluated as false.  It does this 
> specifically for each function you request.
> 
>       This is a stupid hack for the following reasons:
> 
>       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.

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

Therefore irrelevant.

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

>       4) If 0 or undef is not an invalid result for a function, it also 
> can't be wrapped with Fatal (this is different from #3 in that a 
> function may return -1 to indicate failure).

See the answer to (3). Perl functions have no excuse for doing this.

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

>       It's a bad hack.  I apologize if you wrote it...or whatever makes 
>       you care for it so much, but an inconsistency or inaccuracy in error 
> handling methodology is worse than one that puts a greater burden on 
> the programmer.

The inconsistency is in your code. Perl is not appreciably
inconsistant in the way it returns success or failure, and perl code
should follow that convention. There are many places where the
convention must be followed or else things will break.

Even if you *do* have a function that returns in a really stupid
fashion, writing a wrapper for it is pathetically easy. Fatal is a
keystroke optimisation, it doesn't do anything remotely difficult.

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.

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.

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

signature.asc
Description: Digital signature