Jesper Udbys personal opinions

The SoapConnection java class sports a private static inner Exception, the SessionTimedOutException. This Exception is used internally only to quickly pass control from the parseDetail() method back to the send() method.

This is bad practice, using an Exception to control flow of execution. And in this case the infrastructure is doing exception handling in the first place… There has to be a better way.

Continue reading →

I have a number of situations where a RequestTimedOutException would be appropriate instead of just a ConnectionException when SoapConnection.send() encounters a SocketTimeoutException.

This would ease retry implementations (related to timeouts) in that they would only have to consider a special type of exception and does not have to revert to parsing exception messages.

If a RequestTimedOutException extends ConnectionException the handling of SocketTimeoutException in the SoapConnection class can be done without changing the api. It is a simple matter of changing the type of exception thrown as response to SocketTimeoutExceptions.

E.g. in SoapConnection:

112
113
114
115
116
117

        } catch (SocketTimeoutException e) {
            long timeTaken = System.currentTimeMillis() - startTime;
            throw new RequestTimedOutException("Request to " + url + " timed out. TimeTaken=" + timeTaken +
                    " ConnectionTimeout=" + config.getConnectionTimeout() + " ReadTimeout=" + 
                    config.getReadTimeout(), e);
        }

And the RequestTimedOutException, e.g. at the bottom of SoapConnection:

    public static class RequestTimedOutException extends ConnectionException {
        private static final long serialVersionUID = 1L;
 
        private RequestTimedOutException(String message, Exception e) {
            super(message, e);
        }
    }

WSC issue 67.

I hate compiler warnings. These little yellow warning signs in Eclipse annoys me. I will go far to avoid compiler warnings in my own code.

But what about generated code? Actually generated code is the worst as it does not make sense to correct the code to remove the warnings – they will reappear when the code is regenerated. And it demonstrates sloppiness in the code generation tool.

In this article I will work through and demonstrate how to remove the compiler warnings from the wsc generated code, and some of the infrastructure code as well.

Continue reading →