On Fri, May 1, 2020 at 12:28 PM Andrew Barnert <abarn...@yahoo.com> wrote:
> > 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. > > I don’t think there are many cases where a standardized .errno would > help—and I think most such cases would be better served by separate > exceptions. With OSError, errno was a problem to be fixed, not an ideal > solution to emulate everywhere. > I will note that wrote is response to someone else suggesting that that was the solution to the OP's problem. If the "policy" is that some information should be tacked on to a fairly generic exception, rather than crating a bunch of subclasses if that exception, then I'm suggesting that there should be a standardized way to do that. > You do often need to be able to get more information, and that is a > problem, but I think it usually needs to be specific to each exception, not > something generic. > but does that mean there can't be a more standardized way to "add more information" maybe not -- I can't say I've thougth deeply about it, but we could go ONE step better: as far as I can tell, the only thing at all a standard is the exceptions all have a .args attribute wich is a tuple of ??? IN practic,e the zeroth element of that tuple is the "Error Message", but it could be any old thing. Python2 DID have a .message attribute -- I guess I should go look and find documentation for the reasoning behind that, but it does seem like a step backwards to me. As for parsing the error message, that usually comes up because there’s > auxiliary information that you need but that isn’t accessible. For example, > in 2.x, to get the filename that failed to open, you had to regex .args[0], > and that sucked. But the fix was to add a .filename to all of the relevant > exceptions, and now it’s great. If you need to be able to get the failing > string for int(s) raising a ValueError today, you have to regex .args[0], > and that sucks. Do people actually need to do that? If so, there should be > a .string or something that carries that information; an .errno won’t help. > but it does seem like this could be a bit more standardized. in those two cases, you have the data passed in that caused the failure -- could they bwoth use .input_value or something? Maybe it's better to have a use-specific name, maybe not. I'm not going to be able to motivate this well, so I should probably just stop until/unless I get some more time to dig back in my archives and find examples when this was an issue, but I know that every time I've wanted a bit more info from an Exception, I realized that .args is the ONLY standard place for any info -- and thought "really?" It seems like every year or two, someone suggests that we should go through > the stdlib and fix all the exceptions to be reasonably distinguishable and > to make their relevant information more accessible, and I don’t think > anyone ever has a problem with that, it’s just that nobody’s ever willing > to volunteer to survey every place a builtin or stdlib raises, list them > all, and work out exactly what should be changed and where. > Probably so, but it seems that no one's going to do that work unless they think it will be accepted -- kin dof like how Ram proposed this in vague and hyperbolic terms, rather than providing a big list of all the places he thought needed improvement. But it seems clear that "doing a big revamp if all the Exceptions and adding alot more subclasses" is not supported. Which doesn't means that a few more expansions wouldn't be excepted. So folks that like this idea may be best served by finding the lowest hanging fruit, and suggesting jsut a few. -CHB -- Christopher Barker, PhD Python Language Consulting - Teaching - Scientific Software Development - Desktop GUI and Web Development - wxPython, numpy, scipy, Cython
_______________________________________________ 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/OML342YY3CJPVE7YLHDXIQUMAES6SEX4/ Code of Conduct: http://python.org/psf/codeofconduct/
