Hi Ram, I think you are confusing the exception type with the exception reason. By adding 100 more exception types, you don't make things easier, but instead you complicate things, since we'd all have to memorize those 100 exception types.
That said, enhancing the error reasons texts is certainly something that would help everyone. Adding more exception types to the stack makes sense when there's a dedicated need to catch only specific sub types, but even there it's already possible to add this extra information to the exception objects as e.g. .errno or similar attribute. Thanks, -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Experts (#1, May 01 2020) >>> Python Projects, Coaching and Support ... https://www.egenix.com/ >>> Python Product Development ... https://consulting.egenix.com/ ________________________________________________________________________ ::: We implement business ideas - efficiently in both time and costs ::: eGenix.com Software, Skills and Services GmbH Pastor-Loeh-Str.48 D-40764 Langenfeld, Germany. CEO Dipl.-Math. Marc-Andre Lemburg Registered at Amtsgericht Duesseldorf: HRB 46611 https://www.egenix.com/company/contact/ https://www.malemburg.com/ On 01.05.2020 08:48, Ram Rachum wrote: > Hi, > > Here's something I wanted in Python for many years. If this has been > discussed in the past, please refer me to that discussion. > > On one hand, it's something that I can't imagine the python-dev > community supporting. On the other hand, it would maintain backward > compatibility. > > I wish there were a 100 more built-in exceptions in Python, that will be > very specific about what went wrong. > > If I do this: > > >>> x, y = range(3) > > I know it'll raise a ValueError, because I've memorized that, but it did > take me a few years to remember where I should expect ValueError and > where I should expect TypeError. > > It would be nice if the operation above raised UnpackingOverflowError, > which will be a subclass of UnpackingError, along with > UnpackingUnderflowError. UnpackingError can be a subclass of > ValueError, for backward compatibility. > > Similarly, if I did this: > > >>> def f(x, y): return x + y > >>> f(1) > > I would get a TypeError. Would be a lot cooler if I got > MissingArgumentsError, which would be a subclass of SignatureError, > which would be a subclass of TypeError. > > There are 2 reasons I want this: > > 1. When I'm writing a try..except clause, I want to catch a specific > exception like MissingArgumentsError rather than ValueError or > TypeError. They're too ubiquitous. I don't want some other unexpected > failure producing the same ValueError and triggering my except clause. > > 2. When I get an error, especially from some shitty corporate system > that truncates the traceback, I want to get as many hints as possible > about what went wrong. > > It's true that today, most Python exceptions have good text in their > message, like "TypeError: f() missing 1 required positional argument: > 'y'". But that isn't guaranteed everywhere, and specific exception types > could help. > > > What do you think? > > > Ram. > > _______________________________________________ > Python-ideas mailing list -- python-ideas@python.org > To unsubscribe send an email to python-ideas-le...@python.org > https://mail.python.org/mailman3/lists/python-ideas.python.org/ > Message archived at > https://mail.python.org/archives/list/python-ideas@python.org/message/XZXWXICKS2RCQLLX73NJOWCJPRY7IUX2/ > Code of Conduct: http://python.org/psf/codeofconduct/ > _______________________________________________ Python-ideas mailing list -- python-ideas@python.org To unsubscribe send an email to python-ideas-le...@python.org https://mail.python.org/mailman3/lists/python-ideas.python.org/ Message archived at https://mail.python.org/archives/list/python-ideas@python.org/message/HKZTPPY5JHMAP7QSV7ALCT6O6TLETCDP/ Code of Conduct: http://python.org/psf/codeofconduct/
