Compared to conditionals, programming by Exception is slow. You can use the timeit module (or the IPython %timeit magic function) to run comparative performance benchmarks.
https://en.wikipedia.org/wiki/Coding_by_exception : https://en.wikipedia.org/wiki/Exception_handling#Criticism : > Exception handling is often not handled correctly in software, especially when there are multiple sources of exceptions; data flow analysis of 5 million lines of Java code found over 1300 exception handling defects.[15] Citing multiple prior studies by others (1999–2004) and their own results, Weimer and Necula wrote that a significant problem with exceptions is that they "create hidden control-flow paths that are difficult for programmers to reason about".[15]:8:27 > > Go was initially released with exception handling explicitly omitted, with the developers arguing that it obfuscated control flow.[16] Later, the exception-like panic/recover mechanism was added to the language, which the Go authors > ** advise using only for unrecoverable errors that should halt the entire process.[17][18][19][20] ** > > Exceptions, as unstructured flow, increase the risk of resource leaks (such as escaping a section locked by a mutex, or one temporarily holding a file open) or inconsistent state. There are various techniques for resource management in the presence of exceptions, most commonly combining the dispose pattern with some form of unwind protection (like a finally clause), which automatically releases the resource when control exits a section of code. [Emphasis added] Neither of these documents advise against using Exceptions for control flow: - https://docs.python.org/3/tutorial/errors.html#exceptions - https://docs.python.org/3/library/exceptions.html One alternative to Exceptions is to return a (value, err) tuple and have conditionals for each possible value of err. (value, err) = func() if err is not None: # [...] On Tue, Oct 13, 2020 at 1:10 PM Wes Turner <wes.tur...@gmail.com> wrote: > Exception.args holds the arguments passed to the exception. > > You could add type checking with dataclass, or you can just access > Exception.args or > sys.exc_info().args: > > ```python > class Exception2(Exception): > pass > > > > try: > raise Exception2('error str', dict(a='1', b=2)) > except Exception2 as e: > print(('args', e.args)) > assert e.args[0] == 'error str' > assert e.args[1] == dict(a='1', b=2) > > import sys > type_, value, traceback = sys.exc_info() > assert value.args[0] == 'error str' > assert value.args[1] == dict(a='1', b=2) > > > > # ('args', ('error str', {'a': '1', 'b': 2})) > ``` > > On Tue, Oct 13, 2020 at 12:56 PM David Mertz <me...@gnosis.cx> wrote: > >> On Tue, Oct 13, 2020 at 6:18 AM Steven D'Aprano <st...@pearwood.info> >> wrote: >> >>> I don't think that a two line class (perhaps a couple of extra >>> lines if you give it a docstring) justifies the name "boilerplate": >>> >>> class MySpecialException(Exception): >>> pass >>> >> >> I think that in 22 years of using Python, I have never written an >> exception that took more than these two lines of code. >> >> Heck, I even have my memory jogged of string exceptions reading this. >> When did those go away fully, 1.5.2? 2.1? >> >> I DID in the discussion, immediately think of making an exception a >> dataclass, as someone else replied with. I guess if you want cargo in your >> exception, that's a pretty good way to do it. But really the ONLY thing I >> ever want in an exception is an inheritance tree. An exception feels like >> a really unnatural way to pass around data (that said, there are a few >> exceptions written by other libraries where some attribute or another is >> useful in my except blocks. Perhaps I should consider that, beyond >> inspecting the traceback when needed. >> >> If you really want a snazzy highly-parameterized exception, write it >> yourself as a class factory. I won't particularly like the antipattern, >> but it's available now. >> >> if some_bad_thing: >> raise ExceptionMaker("BadStuffErrror", details, plus, more_details) >> >> Implementation of 'ExceptionMaker' left to readers. But it's possible to >> write once. >> >> >> _______________________________________________ >> 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/M7LP4OMSEU47MBWX75KGBM7343SH5XGI/ >> 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/6AF4DFK6SMZZHZRJKD7BO7L2MVS7QEDF/ Code of Conduct: http://python.org/psf/codeofconduct/
