I'm working on a project that includes a lot of creating/manipulating and reading JSONObjects and arrays but not in a systematic way. So there is JSON code everywhere.
It is ok for me except that every time I work on a JSONObject I got to handle JSONException.
So I created a class that extends JSONObject and Override the put/get methods in it and handled JSONExceptions inside this class.
It made my code way much clearer and I believe it is more than enough for my case.

What do you think?

  • So you are OK with invalid JSON all over the place? – Oded Dec 12 '11 at 10:32
  • I'm generating JSONObjects locally using JSON libraries so I don't think I will get invalid JSONs – Mr.Me Dec 12 '11 at 10:51

I created a class that extends JSONObject and Override the put/get methods in it and handled JSONExceptions inside this class.

This may be perfectly fine or perfectly sucky depending on how you handled the exception inside that class. When (when, not if) an exception arises, what happens? Perhaps there is some central error handler that you're using? How do the users of your JSONObject subclass know if something went awry?

Or do you have a guarantee that things simply can't go awry? If yes, then you should still have some sort of assertion mechanism to catch the impossible.

Exceptions and errors can be handled in myriad of ways. Most of the ways are all right as long as things crash early, with as specific error message as possible, and won't just fail silently later on.

  • Thanks . I will work on throwing Runtime Exceptions if something went wrong , eventhough I can't see that hapenning in the way I'm using JSON. – Mr.Me Dec 12 '11 at 12:14
  • 4
    Throwing a runtime exception will make your application crash and burn on the user when it hits the unexpected. An assertion likely won't (they are disabled by default IIRC, and should definitely be disabled in production code). You can always do something like assert false : "Invalid JSON: " + json.toString(); if you don't want to repeat any checks. – a CVn Dec 12 '11 at 12:22

From what I understand, you prefer not handling checked exceptions. The simplest solution might be that your extended class simply wraps checked JSON exception into new Runtime Exception.

  • Yes That is exactly what I'm going to do – Mr.Me Dec 12 '11 at 12:15
  • But how are you going to deal with that RuntimeException? For me, the point of catching a Checked Exception is being able to try and deal with the problem gracefully. So you might be able to retry the JSON operation, or gently close the application ensuring the resources are all cleaned up etc. – Martijn Verburg Dec 12 '11 at 13:51
  • The OP stated that such error should never happen ( statement always taken with a pinch of salt). From that I can conclude there is no simple way to retry the the JSON operation. However, gently closing the application is quite important, but handling Runtime exception should be done application level anyway to support graceful death. All in all, those are important questions. – bbaja42 Dec 12 '11 at 15:28

1) Bubble the exception up to a recoverable place in your code. Then deal with it.

2) How are you getting to the point where you are worried about getting invalid data? I like to keep my data as clean as possible. If you do get an exception at that point then you can treat it like an exception.

3) You really should care about your code. Go read thedailywtf.com to see about people who are "ok" with their (messy) code.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.