On Fri, May 1, 2020 at 1:38 AM M.-A. Lemburg
Adding more exception types to the stack makes sense when there's a dedicated need to catch only specific sub types, but even there it's already possible to add this extra information to the exception objects as e.g. .errno or similar attribute.
Maybe it's too late for this, but I would love it if ".errno or similar" were more standardized. As it is, every exception may have it's own way to find out more about exactly what caused it, and often you are left with parsing the message if you really want to know. Honestly, I've never written production code that does that -- but I don't think that's because there's no need for it, but because, well, parsing an error message is pretty painful, and just seems "wrong". I'm not sure how this could reasonably work, but maybe we could standardize that all Exceptions have an .errno attribute, and a standard mapping between the errorno and a message, or, .... Even if most Exceptions would have only a single error number, this would be a standardized way to add extra info to any Exception. And frankly I've always thought it odd that the way to get the message was to grab the first element in .args -- it's a defacto standard, but wouldn't it be better to make it a actual standard? Not well thought out, but this may be a way to address Ram's issues, while not massively cluttering up the Exception namespace. NOTE: I'm not sure where I come down on this, but having to "memorize" a bunch more exceptions does not concern me in the least. I pretty much always write code or tests that trigger the Exception I'm going to catch to make sure I've got the right one anyway. Sure, I'm pretty familiar with ValueError and TypeError, but there are a lot more than I can keep in my brain at one time anyway, and I need to spell it right, and all that. The one complication I DO see to this approach is that we'd have a lot of Exceptions that were subclasses of more general ones, and when you see it, it would not be obvious what the hierarchy is, so folks would tend to use the fine-grained exception over the more general one, even if that wasn't appropriate. -CHB -- Christopher Barker, PhD Python Language Consulting - Teaching - Scientific Software Development - Desktop GUI and Web Development - wxPython, numpy, scipy, Cython