Re: [Gnu-arch-users] Nit

[Dustin Sallings]

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

> > > > > > > I have never even encountered a program where this was not true,
> > > > > > > let
> > > > > > > alone written one.

> > > > > > [...]

> >         Well, at the top of this deeply quoted text, you hadn't seen it.
> >         Now you have.
>
> That's simply wrong, and doesn't match anything I've said. Please
> *stop* attributing things to me that I did not say.

        Uh, whatever.

> > > >         I have seen very few applications, if any, that consider ENOSPC a
> > > > temporary error.  I have a lot of programs that write to disk.  
> > > > That's
> > > > their job.  If there is no space, they cannot do their job.  What 
> > > > are
> > > > they supposed to instead?
> > >
> > > Wait for more space, usually.
> >
> >         Can you cite an application (other than something you've written,
> > apparently) where this actually happens?
>
> Not off the top of my head, I'd have to go check a few things to find
> one without this bug. It's distressingly common.

	That's cool.  I'm really interested in this.  Everything I've tried so 
far has failed quickly when disk space ran out.

> >         You'd be part of the way there if you narrowed its reaction down to
> > only one of the two values perl considers false.
>
> Once again you are showing your inexperience. There are three false
> values in perl.

	Hah.  I expected that.  I'd actually go with more than that.  For 
example:

        undef: false
        "": false
        0: false
        0.0: false
        "0": false
        "0.0": true (huh?)

> > The rest is dealing
> > with individual functions and their perception of failure.
>
> Trivial.

	Well, yeah, just involves reading the docs for all of the things and 
producing hand-made wrappers to deal with inconsistencies.  It's not a 
lot of mental work, just tedious.

> > > No, that is not the only goal. Raising an exception on every error
> > > might accomplish this, but it would have other disadvantages that are
> > > unnecessary. Hence, perl does not do this - particularly since that
> > > exact result can be generated fairly easily.
> >
> >         You make it sound as if you sat through the meeting where they, um,
> > ``designed'' the error reporting for perl.
>
> You make it sound as if there were not several large and heavy books
> describing how and *why* perl works the way it does, or as if the
> design decisions behind perl were not one of the *most common*
> subjects of lectures by Larry Wall.

	I recognize that name, isn't he the guy who said, ``Perl is worse than 
Python because people wanted it worse.''  ?

> >         That's fine, I don't want the code...even if you don't ``have to
> >         think about [it].''
>
> Do you often spend this much time complaining about the lack of a
> module which you don't even want?

	I'm not complaining about the lack of a module, I'm describing why I 
believe it's a stupid hack.  You're saying I'm wrong because it's 
``trivial'' to add enough stuff to it to get it doing what it's 
documented as doing regardless of inconsistent built-in functions.

> >         Fatal, a module that was written to ``replace functions with
> > equivalents which succeed or die,'' does not work for certain core
> > functions, to be specific.
>
> And nor was it intended to. The reason for its existance is pretty
> obvious to me, since I've spent more than 30 seconds (nearly five
> minutes, I'd estimate) thinking about how to go about making all the
> primitives throw exceptions on error.

	This is the part I don't get.  Why would it not be intended to do what 
it's documented to do?

> > > So it's not a perl function at all, it's a C function. Don't expect C
> > > functions to behave like perl functions.
> > >
> > > The whole point of POSIX is to be the thinnest reasonale wrapper
> > > possible around a bunch of C functions. It is very rarely necessary 
> > > to
> > > use it; an experienced perl programmer should always check twice
> > > before calling a function from POSIX, because there's probably a perl
> > > version that's preferable.
> >
> >         Yes, as is clearly stated in the POSIX perldoc...somewhere between
> > 	the parts where it says it gave them ``perl-ish interfaces'' and 
> > ``It's a
> > great source of wisdom.''
>
> No it isn't. What are you talking about?

	This is another example about how I'm a bad perl programmer because I 
don't know some secret knowledge and instead go by what's in the 
documentation.

> > 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.
>
> It is the paragraph to which you were originally replying.

	Sorry, I didn't realize you were going that far back there.  I will 
agree that Other People's Code is often ugly.  However, I don't see a 
justification for ``especially java.''  In my experience, third-party 
java libs can be bad, but they aren't usually that inconsistent from 
the rest of the language.  It takes work to avoid exceptions in java.  
Bad libs tend to throw misleading exceptions, or just 
java.lang.Exception, etc...

	Probably the #1 feature of java is the vast availability of good 
libraries, though.

--
SPY                      My girlfriend asked me which one I like better.
pub  1024/3CAE01D5 1994/11/03 Dustin Sallings <address@hidden>
|    Key fingerprint =  87 02 57 08 02 D0 DA D6  C8 0F 3E 65 51 98 D8 BE
L_______________________ I hope the answer won't upset her. ____________