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