Les Morgan wrote:
IMO: EVERY possible exception should be caught. Once you catch that exception, then what to do has to be based on your business rules, nobody else can really tell you what they are.
I wouldn't anticipate an out of memory problem in the first place, so I wouldn't even think of catching one. If I suffer a un‑declared null pointer exception or arithmetic exception, I shall probably have to go through the code to work out how to correct the problem. In the following case however, it might be possible to correct the problem “in‑flight”.So most unchecked exceptions are best allowed to propagate and (good grief!) I have re‑invented “declare or handle” as in the Java™ Tutorials.
What am I going to do aboiut that exception?
1. GET /uri/<storeId>/orders, This api will return list of store orders(array of JSON object). Internal logic of API is like that it will collect stores order ids from different source(step 1) and start collecting details(step 2) for each order and while collecting order detail for any order it may get exception(may be order got corrupted by some process)
2. User object is injected by framework in our code. We can get user attributes by its getProperty method...