On Thu, Feb 21, 2019 at 10:34 PM Ben Rudiak-Gould <benrud...@gmail.com> wrote:
> > It's well documented how checked exceptions lead to bad code. > > Please cite a paper. I know "everyone knows" that they're bad, but > "everyone knows" a lot of things. > This is one of the original interviews touching why checked exceptions were not made part of C#: https://www.artima.com/intv/handcuffs.html The problem is that a code fragment should only catch exceptions that it expects, because it won't know what to do anything else but to wrap the exception into one of the enclosing type. But if every type has to define a SomethingWentWrongInTypeException wrapper exception, it's logical that all of them inherit from a standard SomethingWentWrongException. Having done that, the type-specific generic exceptions are of no value, because any code wanting to guard against the unexpected will just catch SomethingWentWrongException. And that brings us back to square one, which is letting unexpected exceptions through to wherever a clean shutdown or restart of the subsystem can be done. Then, if exceptions are going to be part of a type, there should be a way to express the semantics of them (like in Eiffel), so stack.pop();stack.push(x) doesn't have to catch StackFullException. In the end, I think that allowing type-hints about exceptions that may be raised is quite useful, as long as they are not checked/enforced (in the style of Java). Many times I've missed a PyCharm hint me about the actual exceptions a given call may actually raise. Newer languages like Go and Swift shy away from exceptions because of the tendency to: try: # something except: print('oops!) -- Juancarlo *Añez*
_______________________________________________ Python-ideas mailing list Python-ideas@python.org https://mail.python.org/mailman/listinfo/python-ideas Code of Conduct: http://python.org/psf/codeofconduct/
