First release of Shed Skin, a Python-to-C++ compiler.
Mark Dufour
mark.dufour at gmail.com
Tue Sep 13 06:21:02 EDT 2005
More information about the Python-list mailing list
Tue Sep 13 06:21:02 EDT 2005
- Previous message (by thread): First release of Shed Skin, a Python-to-C++ compiler.
- Next message (by thread): First release of Shed Skin, a Python-to-C++ compiler.
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
> You forgot to check for an error when: > o when you wrote f.error [attribute "error" might not exist e.g. f is > None] > o you called str(f.error) [might contain unicode characters that can't > be converted to a string using the default > encoding] > o when you used the % operator [format string might be wrong] > And, of course, pretty much every expression can result in a memory error. I don't mind the program bailing out in such a case and telling me where it went wrong, so I can fix the problem. I just don't really see the need for catching exceptions yourself. Especially not in well-tested code, potentially to be compiled. > Exception handling is a boon because almost EVERY expression that you > write can result in a error and checking each one is tedious in the > extreme. So people forget and then their programs exhibit very odd > behavior that is very difficult to debug. What do you mean odd behaviour? If they don't catch exceptions, the program will bail out, showing what went wrong, yeah? > If you look at the Python C source, you'll notice that probably 50% of > the code is devoted to error handling (that was a guess). That's a lot of error handling.. thanks! mark.
- Previous message (by thread): First release of Shed Skin, a Python-to-C++ compiler.
- Next message (by thread): First release of Shed Skin, a Python-to-C++ compiler.
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
More information about the Python-list mailing list