On 23/07/19 11:00 AM, Ethan Furman wrote:
On 07/20/2019 05:02 PM, DL Neil wrote:
Upon closer inspection, I realised it didn't just fail; it failed
badly! Some silly, little, boy had imported the PythonEnvironment
class but failed to ALSO import PythonVersionError. So, the reported
error was not the expected exception!
I don't understand the significance of not importing PythonVersionError:
- PythonEnvironment does not need it to be imported
- when PythonEnvironment raises PythonVersionError you still get
PythonVersionError
- if your code says `except PythonVersionError` and you haven't imported
it you'll get a NameError
So, what's the issue?
Have I correctly understood the question?
NameError conveys nothing to the user.
PythonVersionError is more communicative - and speaks volumes to 'us'.
The mainline code is something like:
p = PythonEnvironment()
try:
p.compatibility( ...spec... ) # eg must be Py3 not 2.n
except PythonVersionError:
print( more illuminating errmsg )
If I am 'the user' I'd be quite happy without the try...except; but mere
mortals need/deserve something more. Accordingly, the PythonVersionError
custom exception/class.
Yes, we could trap NameError, but that might also catch other
name-errors (unlikely in this example, but 'just sayin'). Thus the
greater specificity of the custom class.
NB please see alternative 'solution' proposed (for critique) as "Nesting
Custom Errors in Classes" discussion topic.
--
Regards =dn
--
https://mail.python.org/mailman/listinfo/python-list
