Summary
Lotus Script has a nice feature for exception handling called “resume next”. Java is missing this feature. This article shows an OOP way to implement it when looping an array.
The Task
Imagine you have a class UrlsContentCollector. You provide an URL[] and the collector gives you all the content of the given urls in one big chunk. What is your idea about handling exceptions here? Consider this: One of your applications named “Nippi” using the UrlsContentCollector is picky about the content. This application will produce bogus results, if there is any error in fetching the content e.g. one of the given urls is unreachable. There is another application called “Bob”. “Bob” is a little indifferent. One url unreachable? What the heck! Write a log entry and go on.
On the one hand you need to throw exceptions because of “Nippi”. But this will disturb “Bob”. “Bob” can decide to ignore the exceptions but it cannot get back to the point where the exceptions was raised to continue processing the list of urls.
Do you think about implementing UrlsContentCollector twice? A “noisy” implementation and a “quiet” one? Using reflections and if-blocks in order to decide what to do? I think there is a better way. Or two.
The Clients Decide
“Nippi” and “Bob” both use UrlsContentCollector, let’s call them clients. My idea is this: The UrlsContentCollector does not throw an exception but it notifies the client of the exception. In response the client tells the UrlsContentCollector wether to stop processing or not.
This is easy! Notification is done via a pattern called “observer“. Its interface needs a method with an exception as parameter and a boolean in its answer. “Nippi” and “Bob” use the ExceptionObserver. Being notified they react differently. UrlsContentCollector has a chance to resume if the client wants it to.
Your Exception
“Nippi” and “Bob” do not care about which item caused the problem. “Bob”‘s attitude is “Stop bothering me with details – just go on”. If “Nippi” and “Bob” take a little bit more of a care, then there is an other possibility. Let’s imagine that UrlsContentCollector takes an array of URLs and a starting position i to process the array from i to the end. Further imagine your own exception class ListprocessingInterruptedException. UrlsContentCollector throws a ListprocessingInterruptedException containing the current position processed. The client catching the exception knows where to start over and UrlsContentCollector gives the opportunity to do so.
Conclusion
ExceptionObserver is easy to implement and easy to use. There is no duplicated code necessary here. The classes are loosly coupled. Three reasons why this is a good idea. Maybe this idea is against the odds. This is not the usual way to handle exceptions in java. But as a proverb puts it: “You have to swim against the tide if you want to get to the spring.”
Creating my own exception has an advantage over using the observer pattern. I.e. exception handling is not mixed with other kinds of behaviour. Notably it is not easily confused. As a proverb puts it: “If you are in Rome do as the Romans”. It’s easy to implement, it is DRY, it is loosly coupled.
You can get some bare bones uncommented source code.
Howto decide? Convention rulz cleverness.