Every method invocation throws Exception

[ravishi]

I find it pretty hard to deal with the right errors in code using the Android client because every Java method that reaches the web service is currently signed with "throws Exception".

Because of that, it's pretty hard to identify exaclty what can go wrong inside the client's code. We know that there can occur networking problems, IO errors, HTTP errors, exceptions returned by the remote server, by the service itself, etc. But since everything is signed just as "exception" that doesn't help on quickly identifying what errors my code is going to have to deal with, which leads to bad code.

Now, I had some working code before switching over to liferay-mobile-sdk on Android, and I guess I could try to clean up some of this exception noise. Would that be useful?

[yuchi]

This is what we do on Liferay Connector, if it helps.

[ravishi]

Oh, thanks for that. But I was talking about Java Exceptions on Android's client code. Will try to clarify that on the OP.

[yuchi]

Oh, I thought you were talking about mapping Liferay exceptions to concrete Exceptions.

[ravishi]

That will definitely be useful to me, so thanks anyway!

[brunofarache]

Hi @ravishi, are you saying we should separate each method exception into several Exceptions types? Like "throws ServerException, IOException, RedirectException"?

[ravishi]

Hey, @brunofarache, that's right.

In my previous code I had IOException, ServerException and JSONException. That way I could easily identify if the exception was caused by a network error (IOException), a data error while loading the returned objects (JSONException) or a exception sent by the remote web service (ServerException). We could probably specialize some more exceptions, the whole point being making clearer to client code what is actually happening and how that should be notified (or even if it should be silenced or not) to the user.

[brunofarache]

OK, I can try to split them and regenerate all services to see how it goes.

In our apps we don't really care much about the Exception type. The only one that makes some difference is RedirectException, which tells us to make a second request with the redirected URL. Apart from that, most Exceptions are not recoverable.

[ravishi]

I'll fork this and try to help with that. We plan to make our app somewhat lenient to connectivity problems (by caching stuff locally and showing at least some dirty data to the user instead of nothing), so I'm really interested in having some sort of distinction of exceptions here. I guess I will be able to submit you a patch with some work soon.

[brunofarache]

Agree, I see your point about being hard to identify which type of Exception the inner code would throw.

Waiting for your patch, thanks!

[brunofarache]

Closing this in the meantime.