[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Gnu-arch-users] Nit
From: |
Andrew Suffield |
Subject: |
Re: [Gnu-arch-users] Nit |
Date: |
Tue, 21 Oct 2003 18:52:47 +0100 |
User-agent: |
Mutt/1.5.4i |
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
- Re: [Gnu-arch-users] Nit, (continued)
- Re: [Gnu-arch-users] Nit, Andrew Suffield, 2003/10/22
- Re: [Gnu-arch-users] Nit, Tom Lord, 2003/10/22
- Re: [Gnu-arch-users] Nit, David Brown, 2003/10/22
- Re: [Gnu-arch-users] Nit, Neal D. Becker, 2003/10/22
- Re: [Gnu-arch-users] Nit, Robin Farine, 2003/10/22
- error_t (was Re: [Gnu-arch-users] Nit), Tom Lord, 2003/10/22
- Re: error_t (was Re: [Gnu-arch-users] Nit), Robin Farine, 2003/10/23
- Re: error_t (was Re: [Gnu-arch-users] Nit), Tom Lord, 2003/10/23
- 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 <=
- 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, 2003/10/21
- 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