[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: Python or Perl for a Debian maintainance project?



On Saturday 21 February 2004 19:26, Andrew Suffield wrote:
> On Sat, Feb 21, 2004 at 05:14:17PM +0100, Tilo Schwarz wrote:
> > > > There is no such thing as an I/O operation without an error check in
> > > > Python, and in my book, that is an incredibly Good Thing.
> > >
> > > There's a perl module that calls die "moo" on every IO error if that's
> > > what you really want, but nobody uses it because when they think about
> > > it, that is not what they want. They want a *useful* error
> > > message. Not an obtuse message suggesting that there might be some
> > > sort of error.
> >
> > I couldn't agree more. That's why I like it more like this:
> > > python
> >
> > Python 2.3.3 (#2, Jan 13 2004, 00:47:05)
> > [GCC 3.3.3 20040110 (prerelease) (Debian)] on linux2
> > Type "help", "copyright", "credits" or "license" for more information.
> >
> > >>> input = file('thisfiledoesnotexist')
> >
> > Traceback (most recent call last):
> >   File "<stdin>", line 1, in ?
> > IOError: [Errno 2] No such file or directory: 'thisfiledoesnotexist'
> >
> > >>> input = file('norights.txt')
> >
> > Traceback (most recent call last):
> >   File "<stdin>", line 1, in ?
> > IOError: [Errno 13] Permission denied: 'norights.txt'
> >
> > >>> import os
> > >>> os.rmdir('tmp')
> >
> > Traceback (most recent call last):
> >   File "<stdin>", line 1, in ?
> > OSError: [Errno 39] Directory not empty: 'tmp'
>
> Traceback (most recent call last):
> [ blah blah blah ]
> IOError: [Errno 2] No such file or directory '/tmp/fileag3TSg'
>
> Uhh, what? What file? Why are you even looking there? What were you
> trying to do, and why? This error is useless.

At least it does include the cause for the failed open ("[Errno 2] No such 
file or directory").

> Failed to open scratch file '/tmp/fileag3TSg' (something deleted it in
> mid-run?) at moo line x.
>
> Ah, I need to kill tmpreaper. This error is useful.

O.k., now I know that the open failed and I get a hint how to solve the 
problem, assuming the file actually not exists. But no one knows, as the 
original information about the cause of the failed open is silently stripped. 
That the file doesn't exist is just one of many possible reasons for the 
failed open, just to name a few others:
EINVAL The mode provided to fopen, fdopen, or freopen was invalid.
EACCES The  requested  access to the file is not allowed...
EMFILE The process already has the maximum number of files open.
ENFILE The limit on the total number of files open on the system has been 
reached.
...
If you want write access, there are a few more.

> Generic exception handlers *suck*.

I agree, but handlers giving less information on some problem than the built 
in handler suck even more. One should at least pipe the cause for the error 
through.

Regards,

	Tilo



Reply to: