Re: [Jython-dev] Socket exception handling.

[Alan K. <jyt...@xh...>]

[Alan]
>> B: Leave the status quo as is, and complete the mapping table
>> incrementally over time, with completion coming sometime after the
>> release of jython 2.2.

[Frank]
> I vote for B.  I plan on having a release22-main branch that we can
> eventually release as Jython 2.2.1 -- I'm sure after 2.2 has had a few
> months in the wild, we will find some bugs that compel us to cut
> another release -- and these incremental improvements could make it
> into that (and into 2.x (2.5?) of course)

I think that retaining the exception mapping is the right way to go.

I say this particularly because not doing it will prevent us from 
running cpython modules out of the box.

A good example of this is httplib, which just popped up in a bug report

https://sourceforge.net/tracker/?func=detail&atid=112867&aid=1751963&group_id=12867

There is some code that illustrates the bug, which I copied from the 
cpython httplib documentation.

The code sample in question *never* ran on jython.

First off, httplib uses socket.makefile(), with the resulting file being 
closed after each request. On jython, this always resulted in closing 
the underlying socket, so multiple requests on a httplib.HTTPConnection 
always failed on jython.

When httplib detects that a connection has been closed, and the 
auto_open flag is open, it attempts to re-open the connection. But it 
only detects that situation through cpython-specific error handling, 
whereby it expects a cpython <int, string> exception tuple, as opposed 
to a jython 2.1 java exception.

Now that we're using cpython compatible exception tuples, httplib runs 
smoothly on jython for the first time, giving identical behaviour to 
cpython.

Still, mapping all those java exceptions to the relevant cpython 
exception+errno is not to be quick or easy. To simplify things a little, 
I have now entered all java.net and java.nio exceptions in the exception 
map. So we should hopefully get there a little quicker.

Regards,

Alan.