Path: ...!news.mixmin.net!news.swapon.de!fu-berlin.de!uni-berlin.de!not-for-mail
From: "Loris Bennett" <loris.bennett@fu-berlin.de>
Newsgroups: comp.lang.python
Subject: Re: FileNotFoundError thrown due to file name in file, rather than file itself
Date: Tue, 12 Nov 2024 10:15:47 +0100
Organization: FUB-IT, Freie =?utf-8?Q?Universit=C3=A4t?= Berlin
Lines: 100
Message-ID: <875xosyfr0.fsf@zedat.fu-berlin.de>
References: <87v7wt986z.fsf@zedat.fu-berlin.de>
	<CAJQBtg=UOiOmmHa25EUZtrZO19F1O0_VxCO6gWjZ5ebAMHnXCA@mail.gmail.com>
	<mailman.92.1731341107.4695.python-list@python.org>
Mime-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 8bit
X-Trace: news.uni-berlin.de YxVcmas1QBIRwxDDtYVyUg2omyKenFjRGnfDjRXuSHJdfl
Cancel-Lock: sha1:UmDrsABNAtj8Nm1l3ljCv2aU7mM= sha1:v6OB/ZJq2bkLM+KZGv/VUUXlF6g= sha256:jlKoWppUUz6FfqG2IDlc6YMwJDyzAjUQeZGLHfAqK4c=
User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/28.2 (gnu/linux)
Bytes: 5079

Left Right <olegsivokon@gmail.com> writes:

> Poor error reporting is a very common problem in programming.  Python
> is not anything special in this case.  Of course, it would've been
> better if the error reported what file wasn't found.  But, usually
> these problems are stacking, like in your code.  Unfortunately, it's
> your duty, as the language user, to anticipate those problems and act
> accordingly. Now you've learned that the one file you believe that
> could be the source for the error isn't the only one--well, adjust
> your code to differentiate between those two (and potentially other?)
> cases.  There's very little else you can do beside that.
>
> NB. On the system level, the error has no information about what file
> wasn't found.  It simply returns some numeric value (the famous
> ENOENT) in case when the system call to open a file fails.  Python
> could've been more helpful by figuring out what path caused the
> problem and printing that in the error message, but it doesn't...
> That's why I, myself, never use the vanilla FileNotFoundError, I
> always re-rise it with a customized version that incorporates the
> information about the missing file in the error message.

That sounds like a good idea.

> NB2. It's always a bad idea to print logs to files.  Any sysadmin /
> ops / infra person worth their salt will tell you that.  The only
> place the logs should go to is the standard error.  There are true and
> tried tools that can pick up logs from that point on, and do with them
> whatever your heart desires.  That is, of course, unless you are
> creating system tools for universal log management (in which case, I'd
> question the choice of Python as a suitable language for such a task).
> Unfortunately, even though this has been common knowledge for decades,
> it's still elusive in the world of application development :|

I am not entirely convinced by NB2.  I am, in fact, a sort of sysadmin
person and most of my programs write to a log file.  The programs are
also moderately complex, so a single program might access a database,
query an LDAP server, send email etc., so potentially quite a lot can go
wrong.  They are also not programs whose output I would pipe to another
command.  What would be the advantage of logging to stderr?  Quite apart
from that, I find having a log file a useful for debugging when I am
developing.

Cheers,

Loris


> On Mon, Nov 11, 2024 at 4:00 PM Loris Bennett via Python-list
> <python-list@python.org> wrote:
>>
>> Hi,
>>
>> I have the following in my program:
>>
>>     try:
>>         logging.config.fileConfig(args.config_file)
>>         config = configparser.ConfigParser()
>>         config.read(args.config_file)
>>         if args.verbose:
>>             print(f"Configuration file: {args.config_file}")
>>     except FileNotFoundError:
>>         print(f"Error: configuration file {args.config_file} not found.  Exiting.")
>>         sys.exit(0)
>>
>> and when I ran the program I got the error
>>
>>   Error: configuration file /usr/local/etc/sc_mailer not found.  Exiting.
>>
>> However, this file *does* exist and *can* be read.  By checking the
>> 'filename' attribute of the exception I discovered that the problem was
>> the log file defined *in* the config file, namely
>>
>>   [handler_fileHandler]
>>   class=FileHandler
>>   level=DEBUG
>>   formatter=defaultFormatter
>>   args=('/var/log/my_prog.log', 'a')
>>
>> This log file did not exist.  The exception is thrown by
>>
>>   logging.config.fileConfig(args.config_file)
>>
>> My questions are:
>>
>> 1. Should I be surprised by this behaviour?
>> 2. In terms of generating a helpful error message, how should one
>>    distinguish between the config file not existing and the log file not
>>    existing?
>>
>> Cheers,
>>
>> Loris
>>
>> --
>> This signature is currently under constuction.
>> --
>> https://mail.python.org/mailman/listinfo/python-list
-- 
Dr. Loris Bennett (Herr/Mr)
FUB-IT, Freie Universität Berlin