Pages

Showing posts with label java. Show all posts
Showing posts with label java. Show all posts

Wednesday, 14 May 2014

Jax-RS custom exception handling

One of the nice things about working with JEE is the components available really are pretty standard.  While using JAX-RS, sometimes you need to control how exceptions get processed and fed back to the user.  If an exception is thrown, by default, you'll get some horrible HTTP 500 internal server exception, exposing the internal failings of your web service.

Consider the following gist, this endpoint would be used to view a user based on the Id.

Now, the implementation of this interface would look something like the following, to do the donkey work of actually retrieving the user.

This looks fine, but consider if the userDao was doing some entity business logic, using Query.getSingleResult and the user with this ID didn't exist?

According to the JEE6 API documentation, you'd receive a NoResultException, which would cause an HTTP 500 error exposing your internal server exception, which is definitely something end users shouldn't see. We need to leverage the exception handling of Jax-RS!

First, we need a dumb exception object, appropriately named, which will be what we'll actually throw, consider the code below..

Next, we need to modify our original code to take into account this exception, I've modified the original UserWebService and associated implementation appropriately below.

This will now throw an appropriate exception when a user cannot be found. However, we still need to create a Handler object to convert this exception into an actual JSON response so we get a nice friendly error message. The class below handles this exception and will convert the error message in the exception into a JSON response. The important annotation you'll see on this class is the @Provider annotation.

You'll notice we create an ErrorMessage object to respond to from the web service. This is just a simple dumb object to hold the details of the actual error that'll be marshalled into JSON.

The final step in mapping our exception handler provider to the web-app is to add the following into our web.xml for our webapp.

Now when we call this REST endpoint with a user ID that doesn't exist (let's say "DAG"), we'll happily receive the following JSON response rather than a stacktrace.

Friday, 17 January 2014

Stripping Java string SQL statements automatically

Do you ever get sick of typing out an SQL statement in Java with all the String syntax?

Then, when the statement doesn't work, you have to copy it back into pure SQL to run it to check it works?

This was a pretty common problem for me, so I made a simple syntax stripper http://idavid.co.uk/sqlstripper/ so I could quickly covert from SQL into a Java string and back again.  Consider the following Java String...

String query = "SELECT * " +
"   FROM USERS u" +

"INNER JOIN CODE cd ON cd.userid = u.id " +
"WHERE u.id in ('1','2') ";

This would parse fine if it was being sent into stmt.executeQuery(query)

But it I wanted to run this on SQL server just to see what it produced, I'd have to manually remove all the syntax etc to make it run and generate the following SQL.

SELECT *
FROM USERS u
INNER JOIN CODE cd ON cd.userid = u.id
WHERE u.id in ('1','2')

This is exactly what my SQL stripper does.  It also gives you the ability to paste in an SQL statement into the right hand textbox and convert it into a nicely formatted Java String, so converting the SQL statement above would give...

"SELECT *"
+ " FROM USERS u"
+ " INNER JOIN CODE cd ON cd.userid = u.id"
+ " WHERE u.id in ('1','2')";