1

This question is related to both of these questions - Efficient try / catch block usage? and Dealing with error in data - Idempotent approach.

When I encounter a void while reading a GIS data file I throw an Exception. This Exception is a subclass of java.lang.Exception. The question is of what happens after the void data exception is reached. Post processing would require that I go to another URL where the void filled data file is available and then download that and then proceed to read it in.

From the "efficient-try-catch-block-usage" question it appears doing inside this the catch block is a strict NO. Would it better then instead of throwing an application specific exception it is better to check for a return code or a post condition and proceed to do the post processing ?

1

It depends on how much of a performance hit you can reasonably accept when throwing the exception. If it only happens once, it might not be a big deal. If it happens every line of the file, it could be a huge problem.

Normally exceptions are thrown when something happens that you can't do anything about, and execution is stopped.

  • when a single void is encountered I stop processing that file. I then go to the void filled URL and proceed to download that. You are saying this can be done inside the catch block ? – gansub May 21 '15 at 4:57
  • I'm not a fan of using catch blocks to control program flow, but yes, you could use it like a hacky continue statement. – Robert Harvey May 21 '15 at 5:16
  • Robert Harvey - not a big fan of hacky code :-) – gansub May 21 '15 at 5:24
  • Still, you could think of each file as a separate "process." In that context, exceptions used in this way are perfectly legitimate. – Robert Harvey May 21 '15 at 13:10
  • you are saying it is fine to have detailed application logic inside catch blocks ? – gansub May 21 '15 at 13:23

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.