[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Gnu-arch-users] Nit
From: |
Dustin Sallings |
Subject: |
Re: [Gnu-arch-users] Nit |
Date: |
Tue, 21 Oct 2003 20:13:29 -0700 |
On Tuesday, Oct 21, 2003, at 18:04 US/Pacific, Andrew Suffield wrote:
This is getting off-topic even for an off-topic thread. It's clear
that we all have different ideas about error handling down to defining
what an error is.
To drift a little towards topic, I think it's rather nice to see how
few actual arch problems are being discussed on the list. I've
successfully converted many years worth of CVS myself and am hoping to
get some kind of bidirectional synchronization with the perforce server
at work so I can work offline more.
anyway...
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.
Behaviour which is fortunately easy to turn off. What I said remains
true, no matter how many historical features of unix you point out
that make it inconvinient.
Oh come on. You either haven't seen it, or it's historical and in
every application that hasn't specifically disabled it.
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?
Why are you not reading what I have written?
ENOSPC is not a fatal error. It is a temporary error. It is not
appropriate to abort when it occurs, regardless of whether you are
writing to a pipe or to a file.
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?
Does tla call up Tom and ask him to come over to my house and free up
disk space when it can't do a commit?
Also, why do you keep assuming that the sole purpose of the program is
to write to stdout? It is not appropriate for any program to abort
when its logging mechanism fails, whether that is stdout or a file.
Because that is the sole purpose (or at least an extremely vital part)
of many, many programs I use every day. You know, things like grep,
dd, gzip, tar, find, diff, etc... For example:
dustinti:/Volumes/Test 516% dd if=/dev/zero | gzip -1vc > test.out.gz
gzip: stdout: No space left on device
If you're talking about logging, though... In many of my
applications, it is extremely undesirable for the application to
proceed without logging what it's doing for accounting reasons. If it
can't log it, I can't audit it and I shouldn't do it.
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.
Please be serious. It is not possible for "everyone" to write reliable
software. Only programmers skilled in using the tools available are
capable of writing reliable software.
You are clearly unexperienced in using perl; you should not expect to
get the same degree of flexibility that a serious perl programmer
would.
My last company had on average one hundred programmers working on
about two million lines of perl. I was the guy they called in to solve
the ``hard problems.'' I did all the kinds of stupid hacks like I
consider Fatal to be. I've seen just about everything that can go
wrong in a perl application and fixed it.
The point isn't who's the better perl programmer, it's how can we make
tools that make it easier for people to write more reliable code. If
the most obvious and easiest way to solve a problem isn't the most
reliable, it's not going to be the most common. Experience is
important here, of course, but saying stuff like, ``Ask a perl
programmer to write it for you,'' when the only way they have to make
functions safe is to know every function that is unsafe is certainly
not helping.
To say that 0 should not ever be a valid result from a function
seems a little odd.
Definitely not a perl programmer.
[yet another inconsistency in the perl core functions was here]
I didn't say there were no exceptions. I said they were very few in
number. I also said they were trivial to wrap.
Right, by writing more code. If Fatal were implemented properly, I
wouldn't have to know all of these exceptions to perl's consistency.
Please respond to things I actually said, not to things you would like
to think I said.
That statement is a little revisionist. You're telling me I'm not a
perl programmer because I think that 0 is a perfectly valid result from
a function. I provide examples and you say I'm not responding to
things you said. There clearly is a communication gap here.
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)
Well, I got:
No documentation for perl function `mktime' found
It's part of the POSIX module.
Nobody who is remotely used to using java is going to expect
well-written java code, especially from third parties.
That answer is a bit rhetorical and probably just as true without
specifying a language.
--
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. ____________
- error_t (was Re: [Gnu-arch-users] Nit), (continued)
- Re: [Gnu-arch-users] Nit, Andrew Suffield, 2003/10/23
- Re: [Gnu-arch-users] Nit, Tom Lord, 2003/10/23
- Re: [Gnu-arch-users] Nit, Andrew Suffield, 2003/10/21
- Re: [Gnu-arch-users] Nit, Dustin Sallings, 2003/10/21
- Re: [Gnu-arch-users] Nit, Andrew Suffield, 2003/10/21
- Re: [Gnu-arch-users] Nit, Tom Lord, 2003/10/21
- Re: [Gnu-arch-users] Nit, Robert Collins, 2003/10/22
- Re: [Gnu-arch-users] Nit,
Dustin Sallings <=
- Re: [Gnu-arch-users] Nit, Andrew Suffield, 2003/10/21
- Re: [Gnu-arch-users] Nit, Dustin Sallings, 2003/10/22
- Re: [Gnu-arch-users] Nit, Andrew Suffield, 2003/10/22
- Re: [Gnu-arch-users] Nit, Dustin Sallings, 2003/10/22
- Re: [Gnu-arch-users] Nit, Andrew Suffield, 2003/10/22
- Re: [Gnu-arch-users] Nit, Dustin Sallings, 2003/10/22
- Re: [Gnu-arch-users] Nit, Andrew Suffield, 2003/10/22
- Re: [Gnu-arch-users] Nit, Dustin Sallings, 2003/10/22
- Re: [Gnu-arch-users] Nit, Andrew Suffield, 2003/10/23
- Re: [Gnu-arch-users] Nit, Robert Collins, 2003/10/22