I am a lurker in the IronPython mailing lists. Now that the project is slowly approaching 1.0 release, I have started taking an active interest in the proceedings in the list.
The recent postings on the proposed new exception handling system in IronPython makes interesting reading. Apparently the current model does not provide a nice co-existence of the exception hierarchies of CPython and the .NET CLI. This means that if you call a piece of pure CLI code from inside your Python (IronPython) code and if it raises a CLI exception, you are left stranded in no-man's land if your code only catches Python exceptions.
The proposed new model plans to separate the exception hierarchy into two hieararchies - one for .NET CLI exceptions and one for Python exceptions. The Python exception hierarchy will mirror that of the existing CPython exception class hierarchy. Under this model pure Python and CLI code catching their own exceptions will work the same. When the two worlds collide, i.e when pure Python code tries to catch a CLI exception or when pure CLI code tries to catch a Python exception, the system will convert the exception to the required type.
For example, if the Python code raises EOFError, the CLI code will see an EndOfStreamException. If the CLI code raises FileIOException, the Python code will see an IOError. The error mappings happen automatically.
Some problems still remain unsolved - like what the user should see as an exception traceback; should it be pure Python exceptions or .NET ? The current thinking is that the language should allow both forms in a user-configurable way.
One issue with this model is that in order to map CLI exceptions to Python exceptions you need to go through some kind of mapping for CLI to Python exceptions; this could slow things down a bit. Also, the model requires rethrowing of exceptions whenever the CLI and Python worlds collide.
It will be interesting to wait and watch how the new model develops.
The new exception model is described in detail in this Channel 9 wiki posting.