[IronPython] New proposed exception model for IronPython

[Dino Viehland]

Your proposal is essentially what we have today (we have a separate exception hierarchy that represents Python exceptions that is not correlated with the CLR exception hierarchy in any way).  This actually leads to *less* compatibility with CPython because our exception classes end up showing up as new-style classes instead of old-style classes.  We also are forced to have a slightly different starting point for our exception hierarchy than CPython.  If you see someway we'll be less true to CPython under the proposed model let us know and we can see if we can tweak it to better fit in here.

The current story also makes it more difficult for other CLS code to consume Python code.  For example under today's story no pre-written .NET code will ever catch Python exceptions.  Under the current model .NET developers need to have a dependency on IronPython.dll and then write:

try{

}

catch(PythonIOError){

}

Where all the existing code in the .NET world has:

try{

}catch(IOException){

}

While it might be reasonable to expect that new .NET code written with Python in mind might handle Python exceptions we certainly can't expect that all the existing code be updated to handle this - and certainly not in a timely manner.

Finally I want to point out we don't want to take away your ability to handle .NET exceptions from Python code or raise specific .NET exceptions either.  What you catch will be based upon the type specified in your except clause.  So you can always do:

try:

      o = System.IO.StreamReader('doesnotexist.txt')

except System.IO.IOException, e:

      raise MySpecialIOError

So if you want to provide a more customized exception experience when wrapping calls into .NET code you have the power.  Likewise if you want to throw a CLS exception that doesn't get wrapped under the proposed model you can do that as well:

raise System.Exception('Hello world!')

We don't want to make it hard for the library writer to provide a more customized experience (going either way through the interop story).  If you think the new proposal would do this I'd love to hear some specific examples of what you'd like to be able to accomplish and why you think this would interfere with that.

Thanks for your feedback!


________________________________

From: users-bounces at lists.ironpython.com [mailto:users-bounces at lists.ironpython.com] On Behalf Of Ernst, Nathan
Sent: Thursday, December 15, 2005 6:22 PM
To: Discussion of IronPython
Subject: Re: [IronPython] New proposed exception model for IronPython

Personally, what I would propose would be:

Python libraries throw python exceptions.
.Net libs ought to throw .Net exceptions
Where python libs are implemented using .Net libs, .Net exceptions ought to be wrapped with python libs to the fullest extent reasonably possible.

I believe these three points would lead to a consistent behavior and compatibility with CPython based scripts.

While I like Keith's suggestion of a file-scoped mapping, I'm worried it might even further complicate matters by having to compensate for both schemes (throwing python exceptions, versus throwing .Net exceptions).  I make my suggestion of having it effectively left up to the library implementer because I think it is reasonable to expect standard python libraries to throw python exceptions.  I also think its reasonable that if you are using ironpython specific libraries (or .Net libs directly) to expect to have to handle .Net exceptions.

I'm happy to see the progress that is being made with the new releases (especially with regards to regex support).  I think we're fast approaching the point where ironpython can be used as a replacement for CPython.

Thanks,
Nathan Ernst

________________________________

From: users-bounces at lists.ironpython.com [mailto:users-bounces at lists.ironpython.com] On Behalf Of Keith J. Farmer
Sent: Thursday, December 15, 2005 7:27 PM
To: Discussion of IronPython
Subject: RE: [IronPython] New proposed exception model for IronPython

It's something that should be scoped at the source file level or lower.  Otherwise, someone could map Foo exception to PythonFoo exception, someone else could map Foo to PythonBar, and some poor slob would be left wondering why the first bit of code is suddenly misbehaving.

#BeginMapException <CliException1> <PythonException1>
...
    #BeginMapException <CliException2> <PythonException2>
    ...
    #EndMapException <CliException2>
...
#EndMapException <CliException1>

#BeginMapException <CliException1> <PythonException3>
...
#EndMapException <CliException1>

________________________________

From: users-bounces at lists.ironpython.com on behalf of Dino Viehland
Sent: Thu 12/15/2005 3:40 PM
To: Discussion of IronPython
Subject: Re: [IronPython] New proposed exception model for IronPython

It's an extremely interesting idea and one that I personally like.  Being the new guy I'll want to hear Jim and Martin's input too J.

Ultimately there's no reason why we couldn't either expose supplementary dictionaries that provide for user-defined exception translation or even to expose the dictionaries that we use internally (to allow modifying the systems defaults).  It also seems like it'd be a great way to keep the exception system highly dynamic and give the advanced Python developer more control of it.

I'll make sure to make a note of this to see if we can get it included.

________________________________

From: users-bounces at lists.ironpython.com [mailto:users-bounces at lists.ironpython.com] On Behalf Of Keith J. Farmer
Sent: Thursday, December 15, 2005 3:25 PM
To: Discussion of IronPython
Subject: Re: [IronPython] New proposed exception model for IronPython

Would there be a way to map new exceptions between IP and the CLI?

For example, if I create a new Python exception, and want to bind it to System.ArgumentException, or convsersely if I create a new CLI exception that I want to map to a Python equivalent.  This would be an IronPython-ism, but a worthwhile one I think.


-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/ironpython-users/attachments/20051216/32f35002/attachment.html>