Some basic questions how to handle Exceptions with good style

Question

Ok I have two really basic Exception questions at once:
1. Until now I always threw all exceptions back all the way to my main method and it always worked well for me but now I am sitting at a big project where this method would explode the programm with throwings of very many exceptions in very many methods. So I would like to know if there is a more elegant solution.
2. What do I do with exceptions that will never occur?
Lets say I have a method like this:
void main() {calculate();}
void calculate()
sum(3,5);
void sum(int a,int b)
MathematicsA.initialise("SUM"); // throws AlgorithmNotFoundException, will never occur but has to be handled
}So what is the most elegant way?:
h4. 1. Ignore because it will not happen
void sum(int a,int b)
try {MathematicsA.initialise("SUM");}
catch(AlgorithmNotFoundException) {}
}h4. 2. Print stacktrace and exit
void sum(int a,int b)
try {MathematicsA.initialise("SUM");}
catch(AlgorithmNotFoundException e)
e.printStackTrace();
System.exit();
}h4. 3. throw it everywhere
void main() throws AlgorithmNotFoundException, throws ThousandsOfOtherExceptions  {}
void calculate()  throws AlgorithmNotFoundException, throws HundretsOfOtherExceptions
sum(3,5);
void sum(int a,int b) throws AlgorithmNotFoundException
MathematicsA.initialise("SUM");
}h4. 4. Create special exceptions for every stage
void main() throws MainParametersWrongException
try {calculate();}
catch(Exception e)
  throw new MainParametersWrongException();
void calculate()  throws SumInternalErrorException
try {sum(3,5);}
catch (SumInternalErrorException)    {throw new CalculateException();}
void sum(int a,int b) throws SumInternalErrorException
try
MathematicsA.initialise("SUM");
} catch (AlgorithmNotFoundException e) {
throw new SumInternalErrorException();
}P.S.: Another problem for me is when a method called in a constructor causes an Exception. I don't want to do try/catch everytime I instantiate an object..
Example:
public class MySummation()
     Mathematics mathematics;
     public MySummation()
             mathematics.initialise("SUM"); // throws AlgorithmNotFoundException
     void sum(int x,int y)
          return mathematics.doIt(x,y);
}(sorry for editing all the time, I was not really sure what I really wanted to ask until i realised that I had in fact 2 questions at the same time, and still it is hard to explain what I really want to say with it but now the post is relatively final and I will only add small things)
Edited by: kirdie on Jul 7, 2008 2:21 AM
Edited by: kirdie on Jul 7, 2008 2:25 AM
Edited by: kirdie on Jul 7, 2008 2:33 AM
Edited by: kirdie on Jul 7, 2008 2:34 AM

Answer 1

sphinks wrote:
I`m not a guru, but give my point of view. First of all, the first way is rude. You shouldn`t use try with empty catch. "rude" isn't the word I'd use to describe it. Think about what happens if an exception is thrown. How will you know? Your app fails, and you have NO indication as to why. "stupid" or "suicidal" are better descriptions.
Then for the second way, I`ll reccomend for you use not printStackTrace(); , but use special method for it:
public void outputError (Exception e) {
e.printStackTrace();
}It`ll be better just because if in future you`d like to output error message instead of stack of print it on GUI, you`ll need change only one method, but not all 'try' 'catch' statements for changing e.printStackTrace(); with the call of new output method.I disagree with this. Far be it from me to argue against the DRY principle, but I wouldn't code it this way.
I would not recommend exiting from a catch block like that. It's not a strategy for recovery. Just throw the exception.
Then, the third way also good, but I suppose you should use throws only if the caller method should know that called method have a problem (for example, when you read parametrs from gui, so if params are inccorect, main method of programm should know about it and for example show alert window)."throw it everywhere"? No, throw it until you get to an appropriate handler.
If you're writing layered applications - and you should be - you want to identify the layer that will handle the exception. For example, if I'm writing a web app with a view layer, a service layer, and a persistence layer, and there's a problem in the persistence tier, I'd let the service layer know what the persistence exception was. The service layer might translate that into some other exception with some business meaning. The view layer would translate the business exception into something that would be actionable by the user.
And in all other cases I suppose you should use the fourth way. So I suppose it`s better to combine 2,3,4 ways as I have mentioned above.I don't know that I'd recommend special exceptions for every layer. I'd reuse existing classes where I could (e.g., IllegalArgumentException)
Sorry, I can give you advice how to avoid problem with try-catch in constructor. :-(You shouldn't catch anything that you can't handle. If an exception occurs in a constructor that will compromise the object you're trying to create, by all means just throw the exception. No try/catch needed.
You sound like you're looking for a single cookie cutter approach. I'd recommend thinking instead.
%