3

Would it be at all possible to have an AsyncTask in Android which "Throws" things? If I don't @Override the method, it doesn't get called. If I add the "throws" at the end, there are compiler errors. For example, I want to do something like:

class testThrows extends AsyncTask<String,Void,JSONObject> {
   @Override
   protected JSONTokener doInBackground(<String>... arguments) throws JSONException {
      String jsonString = arguments[0];
      JSONTokener json = new JSONTokener(jsonString);
      JSONObject object = json.getJSONObject("test");
      return object;
   }
}

json.getJSONObject throws a JSONException. Is there any way to do this?

Jessie A. Morris
  • 2,267
  • 21
  • 23
  • 2
    See also http://stackoverflow.com/questions/1600667/method-overriding-and-visibility-in-java – dkarp Jan 11 '11 at 18:12
  • A general why does not work version: http://stackoverflow.com/questions/5875414/method-overriding-and-exceptions , and a Thread#run version: http://stackoverflow.com/questions/1369204/how-to-throw-a-checked-exception-from-a-java-thread – Ciro Santilli OurBigBook.com Mar 16 '15 at 15:30

4 Answers4

6

What you need to do is to wrap the exception with a runtime (unchecked) exception (usually something like IllegalArgumentException; or if nothing matches semantics, plain RuntimeException), and specify checked exception as "root cause" (usually as constructor argument).

And no, you can not broaden set of checked exception: this would be against basic OO principles, similar to how you can not lower visibility (from public to private for example).

StaxMan
  • 113,358
  • 34
  • 211
  • 239
  • No please don't do this. All this will do is make your program compile. It won't actually make it work. You need to tell some body about the exception that can do something about it. – time4tea Jan 11 '11 at 18:15
  • No that is the standard way to do, if (a) you can't throw checked exceptions and (b) there is no way to handle exceptions at that level. Of course if you can handle it there, that's the best way. It is also true that this may be bit of special case, due to task interface. – StaxMan Jan 11 '11 at 18:38
  • time4tea, you're being far too absolute in your position. – duffymo Jan 11 '11 at 18:40
3

You can't override and throw more exceptions; you can only keep the signature as is or throw fewer exceptions.

You can throw unchecked exceptions; those don't change the method signature.

duffymo
  • 305,152
  • 44
  • 369
  • 561
  • 4
    You don't want to do that though. Not really. What will happen to the exception then? it will have disappeared into the calling framework, to be handled who knows how. In this case you should catch the exception that cannot be thrown, and report it via a listener to somebody that can do something sensible with it. – time4tea Jan 11 '11 at 18:11
  • .NET made unchecked exceptions its standard. Are you saying that they were wrong? Java has unchecked exceptions in its API; are you saying they should never be used? I'm not making a value judgment about what should or should not be done; I'm simply pointing out what can be done. – duffymo Jan 11 '11 at 18:39
  • I'm Saying that in java unchecked exceptions represent a different category of error, and that when you use them you need to understand what they mean in the context of the language. In any case just because you can do something rarely means that you should.... – time4tea Jan 11 '11 at 22:33
  • I think we understand what they mean. I disagree with the "rarely" part. I'll ask again - .NET uses unchecked exceptions as their default. Do you think the language is fundamentally, irrevocably flawed as a result? (Hint: the answer is "no".) – duffymo Jan 12 '11 at 00:45
0

You cannot do this. Thanks to Time4Tea, I was able to add callback methods to the class that get called when there is an error. For example:

try {
   JSONTokener json = new JSONTokener(stringToJsonify);
   JSONObject object = json.getJSONObject("test");
} catch (JSONException e){
   onJsonException();
}

Where onJsonException is the class callback method.

Jessie A. Morris
  • 2,267
  • 21
  • 23
-1

You can't override methods in such way.

In your case the solution is to add try-catch block and return false. Also you can add a String field tou your task and fill it with error description. Then you can use it in onPostExecute() method.

Vladimir Ivanov
  • 42,730
  • 18
  • 77
  • 103