Greg> One possible solution, and I think this is what Skip was getting
Greg> at, is to add an "error code" to the exception object that
Greg> identifies the error more reliably than examining the error
Greg> message. It's just the errno/strerror dichotomy: strerror is for
Greg> users, errno is for code. I think Skip is just saying that
Greg> Pythone exception objets need an errno (although it doesn't have
Greg> to be a number). It would probably only make sense to define
Greg> error codes for exceptions that can be raised by Python itself,
Greg> though.
I'm actually allowing the string to be used as the error code. If you raise
TypeError with "not all arguments converted" as the argument, then that
string literal will appear in the definition of exceptions.message_map as
part of a key. The programmer would only refer to the args attribute of the
object being raised.
either-or-makes-no-real-difference-to-me-ly y'rs,
Skip
RetroSearch is an open source project built by @garambo | Open a GitHub Issue
Search and Browse the WWW like it's 1997 | Search results from DuckDuckGo
HTML:
3.2
| Encoding:
UTF-8
| Version:
0.7.4