|
I like this suggestion for its simplicity
and consistency. Here are two more cases: (1) Exceptions generated
from code where no libraries are explicitly used. Here CPython (running
the script) creates a Python exception, and IronPython (running a DLL or EXE) creates
a .NET (or IP) exception, so this shouldn’t be a problem, and (2) Exceptions generated
from user-defined libraries that mix Python and .Net libraries. This is
sometimes done to support a need in the CPython world (as in the case of
Matplotlib, where I wrote a .Net backend – although I seem to be the only
one who uses it J), and other times the library may be intended only to target .Net
(such as a .Net app, which is what Keith’s suggestion addresses). It
is this case that contains the wrinkles, as a library writer cannot predict who
the end user will be. (as Tim Peters might say) glad-to-point-out-problems-that-i-don’t-have-to-solve-ly
y’rs, --Thane From:
[EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Ernst, Nathan Personally, what I would propose would be:
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:
[EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Keith J. Farmer 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:
[EMAIL PROTECTED] on behalf of Dino Viehland 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:
[EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Keith J. Farmer 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.
|
_______________________________________________ users mailing list [email protected] http://lists.ironpython.com/listinfo.cgi/users-ironpython.com
