I think that Exceptions are not designed for message passing: they're
deliberately kept very simple because (1) exceptions are slow; and (2) they
create scope and resource considerations (as I directly quoted above).
Why do you need subclasses for this?
dataobj = dict(a=a, b=b, c=c)
try:
func()
raise MyException("exception message {a}".format(**dataobj), dataobj)
except MyException as e:
logger.exception(e)
print("additional text {b}".format(**dataobj))
print("additional text {b}".format(**e.args[1]))
raise MySpecialException("additionally") from e
Is there a reason to not return a result object with an .error field (or a
value, err tuple) instead of using Exceptions for message passing?
On Tue, Oct 13, 2020 at 1:58 PM <jmwar...@gmail.com> wrote:
> 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/
>
_______________________________________________
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/EX2KPPBYWD5VI726GJCN6PANXP5WVRRI/
Code of Conduct: http://python.org/psf/codeofconduct/
