On 10 March 2000, Guido van Rossum said:
> Skip, I'm not familiar with MySQLdb.py, and I have no idea what your
> example is about. From the rest of the message I feel it's not about
> MySQLdb at all, but about string formatting, butthe point escapes me
> because you never quite show what's in the format string and what
> error that gives. Could you give some examples based on first
> principles? A simple interactive session showing the various errors
> would be helpful...
I think Skip's point was just this: "TypeError" isn't expressive
enough. If you catch TypeError on a statement with multiple possible
type errors, you don't know which one you caught. Same holds for any
exception type, really: a given statement could blow up with ValueError
for any number of reasons. Etc., etc.
One possible solution, and I think this is what Skip was getting at, is
to add an "error code" to the exception object that identifies the error
more reliably than examining the error message. It's just the
errno/strerror dichotomy: strerror is for users, errno is for code. I
think Skip is just saying that Pythone exception objets need an errno
(although it doesn't have to be a number). It would probably only make
sense to define error codes for exceptions that can be raised by Python
itself, though.
Greg
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