> We keep the ability to wrap any exception, while we lose the "fail-fast if > you forget to handle an ExceptionGroup" feature, which was intended as a > kindness towards those who abuse "except Exception".
How is this a kindness? Whenever I've used except Exception or stronger, it was a sanitary barrier around code that might well do unpredictable or even stupid things. Adding a new kind of exception that I hadn't predicted -- including ExceptionGroup -- would certainly fit this description, and I want my driver loop to do what I told it. (Probably log an unexpected exception, and continue with the next record. I honestly don't even want a page, let alone a crash, because data from outside that barrier ... is often bad, and almost never in ways the on-call person can safely fix. And if they don't have time to find it in the logs, then it isn't a priority that week.) > If we adopt this solution then letting an ExceptionGroup escape from code > that is not supposed to raise it, is not a fatal error, it's just some > exception like any other. Good! If we're not coordinating so closely that I already know to handle the ExceptionGroup in advance, then that is exactly what should happen (and except Exception with a log and log analysis is the right way to deal with it). > So there is no longer a distinction between code that raises > ExceptionGroups and code that doesn't. Any code can propagate them, like > any code can raise any other exception. Good; special cases and all. > Does this mean that more code needs to be aware of the possibility of them > showing up? Is that a problem? Honestly, no. You seem to be assuming a very well-controlled environment where any potential problems would be caught long before production. My experience is that such optimism is never warranted, *particularly* at places that claim to have a heavy process to ensure such early (or in-time) bug-catches. > What would we have done here if we were building Python from scratch? Raise anything you want. Or maybe only strings and exceptions. Or maybe only stuff inheriting from a marker class named BaseException ... but we probably wouldn't add a parallel base marker that catch-all code *also* needs to be aware of. (And since we would be starting from scratch, the catch-all wrapper code would certainly not have to be deployed on a conservatively managed server, before lightweight exploratory less-centralized client code could start using it.) -jJ _______________________________________________ Python-Dev mailing list -- python-dev@python.org To unsubscribe send an email to python-dev-le...@python.org https://mail.python.org/mailman3/lists/python-dev.python.org/ Message archived at https://mail.python.org/archives/list/python-dev@python.org/message/TEBYSGMMT3SJRVTPCZQFMHJQPBOV6Q74/ Code of Conduct: http://python.org/psf/codeofconduct/
