Ability to read content after catching exception

[davidekholm]

As you may know, some RESTful servers provide additional information about an error in the http content, but with today's Resty implementation one simpy gets an IOException if there is a 500 server error. Now it's impossible to dig further as the IOException carries no further information :-(

I've made a tiny and fully compatible adjustment to a subclass of Resty to handle this. I let Resty catch IOExeptions, and re-throw RestyExceptions instead. These RestyExceptions are simply subclasses of IOExceptions that embeds an AbstractResource. Problem solved :-)

I'd be happy to provide you my implementation. As I said, it's a tiny and fully compatible adjustment. It does not require any changes to existing users of your library. It just makes it better. My implementation also allows a user to add additional http request parameters which is required by some servers.

Just email me at david@jalbum.net and I'll contribute my code!

[beders]

Sounds good!

---

From: davidekholm notifications@github.com
To: beders/Resty Resty@noreply.github.com
Sent: Friday, September 6, 2013 8:34 AM
Subject: [Resty] Ability to read content after throwing exception (#29)

As you may know, some RESTful servers provide additional information about an error in the http content, but with today's Resty implementation one simpy gets an IOException if there is a 500 server error. Now it's impossible to dig further as the IOException carries no further information :-(
I've made a tiny and fully compatible adjustment to a subclass of Resty to handle this. I let Resty catch IOExeptions, and re-throw RestyExceptions instead. These RestyExceptions are simply subclasses of IOExceptions that embeds an AbstractResource. Problem solved :-)
I'd be happy to provide you my implementation. As I said, it's a tiny and fully compatible adjustment. It does not require any changes to existing users of your library. It just makes it better. My implementation also allows a user to add additional http request parameters which is required by some servers.
Just email me at david@jalbum.net and I'll contribute my code!
—
Reply to this email directly or view it on GitHub.

[davidekholm]

Great to hear from you.
Here's the updated code. Note I subclassed your existing classes. I'd naturally recommend you to implement these changes in the corresponding base classes instead. As you see, I'm simply catching IOException, and if it's possible to read a content reply, I do so and wrap the result as a member variable of RestyException (which in turn is an IOException)

These changes won't affect any clients, just give the ability to inspect error details further.

However, the attached code doesn't include my other addition, which enables the user to add and remove custom http headers. I recommend that you add that ability to the base class too.

Here are the code snippets that I added to implement support for custom http headers. My additions in bold (Resty.html):

private Map<String, String> additionalHeaders; // member variable of Resty

protected <T extends AbstractResource> URLConnection openConnection(URI anUri, T resource) throws IOException, MalformedURLException {
    URLConnection con = anUri.toURL().openConnection(proxy);
    addStandardHeaders(con, resource);
    addAdditionalHeaders(con); // Added line 
    for (Option o : options) {
        o.apply(con);
    }
    return con;
}

/** Add all headers that have been set with the alwaysSend call. */
protected void addAdditionalHeaders(URLConnection con) {
    for (Map.Entry<String, String> header : getAdditionalHeaders().entrySet()) {
        con.addRequestProperty(header.getKey(), header.getValue());
    }
}

/**
 * Tell Resty to send the specified header with each request done on this instance. These headers will also be sent from any resource object returned by this instance. I.e. chained calls will carry
 * over the headers r.json(url).json(get("some.path.to.a.url")); Multiple headers of the same type are not supported (yet).
 * 
 * @param aHeader
 *          the header to send
 * @param aValue
 *          the value
 */
public void alwaysSend(String aHeader, String aValue) {
    getAdditionalHeaders().put(aHeader, aValue);
}

/**
 * Don't send a header that was previously added in the alwaysSend method.
 * 
 * @param aHeader
 *          the header to remove
 */
public void dontSend(String aHeader) {
    getAdditionalHeaders().remove(aHeader);
}

protected Map<String, String> getAdditionalHeaders() {
    if (additionalHeaders == null) {
        additionalHeaders = new HashMap<String, String>();
    }
    return additionalHeaders;
}

Regards
/David

On 7 sep 2013, at 20:14, Jochen Bedersdorfer notifications@github.com wrote:

Sounds good!

---

From: davidekholm notifications@github.com
To: beders/Resty Resty@noreply.github.com
Sent: Friday, September 6, 2013 8:34 AM
Subject: [Resty] Ability to read content after throwing exception (#29)

As you may know, some RESTful servers provide additional information about an error in the http content, but with today's Resty implementation one simpy gets an IOException if there is a 500 server error. Now it's impossible to dig further as the IOException carries no further information :-(
I've made a tiny and fully compatible adjustment to a subclass of Resty to handle this. I let Resty catch IOExeptions, and re-throw RestyExceptions instead. These RestyExceptions are simply subclasses of IOExceptions that embeds an AbstractResource. Problem solved :-)
I'd be happy to provide you my implementation. As I said, it's a tiny and fully compatible adjustment. It does not require any changes to existing users of your library. It just makes it better. My implementation also allows a user to add additional http request parameters which is required by some servers.
Just email me at david@jalbum.net and I'll contribute my code!
—
Reply to this email directly or view it on GitHub.
—
Reply to this email directly or view it on GitHub.

[jpasqua]

Any chance that the exception handling changes will be folded into Resty? It would be really helpful.