Warning: mysqli::__construct(): (HY000/1203): User howardkn already has more than 'max_user_connections' active connections in D:\Inetpub\vhosts\howardknight.net\al.howardknight.net\includes\artfuncs.php on line 21
Failed to connect to MySQL: (1203) User howardkn already has more than 'max_user_connections' active connectionsPath: ...!news.mixmin.net!news.swapon.de!fu-berlin.de!uni-berlin.de!not-for-mail
From: "Loris Bennett"
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>
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 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
> 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