Is "100 more exceptions" hyperbole? Or do you actually mean precisely one hundred more exceptions?
On Fri, May 01, 2020 at 09:48:21AM +0300, Ram Rachum wrote: [...] > 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. If it took you a few years to learn that ValueError is raised for bad values, and TypeError for bad types, then it would probably take you three or four hundred years to memorise an additional 100 exceptions and their spellings. "Is it UnpackingOverflowException or PackingUnderflowError or TooManyValuesUnpackException or ValueUnpackingError or ...???" It took me far too long to learn the difference between UnicodeEncodingError and UnicodeDecodingError. Or is it UnicodeEncodeError and UnicodeDecodeError? It is possible to have too many fine-grained errors as well as too few. [...] > 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. This is an idea I could get behind: https://mail.python.org/archives/list/python-ideas@python.org/message/MXPCNEAWXWJPOHB3DC3QW3S3ZPOFSM4Q/ > 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. Best practice is to put try...except around only a *single* operation which may raise what you want to catch. Of course that's easier said than done, especially since nearly anything can raise nearly anything. But in practice, it is surprisingly more practical than it sounds in theory. > 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. I sympathise, but it's not up to the language to work around the bad practices of lousy corporate systems. > 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? I think that speaking generically, being in favour of "better error messages" and "more fine-grained exceptions" is like being in favour of peace. But the devil is in the details. Peace at what cost? -- Steven _______________________________________________ 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/KUC5A6W2T5Y4TJMYG4KH4CTPRQAYY4FD/ Code of Conduct: http://python.org/psf/codeofconduct/
