I am not advocating removing exception objects so inheritance is still there if needed. As for the data class and exceptions being just two lines, again, I think that makes my point about the boilerplate for most exceptions. Most of the time they are being created just to have a constant to compare against in your except statement so they have little value other than a name. Why waste the lines defining them anywhere other than where they are thrown and where they are handled for most of them? There _are_ times when you want a real object, along with the inheritance and functionality it provides and I am not advocating removing that, but most of this discussion keeps going back to 'Yeah, I just create empty exception objects for the name if I create them at all'. Lets simplify that use case and make it a little more powerful.
That is the boilerplate argument and I think that alone would be worth while even if the argument stuff wasn't added but I think variables and the mentality shift that enables would really be nice. I think that people think of exceptions as a signal with no payload/obfuscated payload because that is how they have seen them, but they don't have to be that way. Exceptions exist because an alternative return is needed, why not allow that communication to be more function like and advertise its parameters like a function would? When I deal with other libraries, like requests, I keep spending time trying to figure out what variables an exception has. There are clearly times where a variable is needed as HTTPError points out. But, where do I get the error code? It isn't obvious from the definition of HTTPError and this obfuscation is a constant issue with exceptions from a lot of libraries. A syntax like what I propose could help clarify the raise except contract and bring obfuscated parameters like code to light. I do agree that it is nice to have some ability to type the call more rigidly, just like a function call. I could see having functions, optionally, advertise exception calls as possible alternate returns but this should be just that, optional just to help out clarity. No need to force an external definition here. This idea is still clearly 'rough' from a syntax/full integration into the language point of view and if it gathers momentum there will be a lot of edge cases to think about, this one included. Finally, I thought about the ExceptionMaker idea myself, to me the handling side is the bigger issue and not the raise side and this doesn't clean that up. The goal is to allow an elegant way of allowing control flow to change in the caller code. It should make it obvious what you are handling along with what variables are related to the flow change. Finally, it should minimize require extra code that, to me, adds little value. This just sounds like a function call, so lets re-use that. _______________________________________________ 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/WYGWE2SQMSQOMHG3IDTFQCCYTGHIHRJQ/ Code of Conduct: http://python.org/psf/codeofconduct/
