> If you don't know how to handle exception for a given method then > you are better off simply throwing it. Just add it to the method > declaration. That's all about that.
I agree with you - however, I have many common functions that are used under several different circumstances where in some cases an error could simply be ignored and in others not. Example: I have common methods for reading configuration files. In some cases it is completely irrelevant if they do not exist because they are only optional - or it would be good to log a warning if the file does not exist. In other cases it is critical if the file can't be found. Passing the exception to the caller means that I am creating boilerplate code for 50 % of the cases. Using a return value does not. But: Reading the arguments of you and others here I got convinced that using exceptions is a good practice. I solution I am thinking of is to write different methods for different usages - one for loading needed config files and one for loading optionals - talking about the sample given above (but I have plenty of similar functions with "conflicting use cases"). --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "The Java Posse" group. To post to this group, send email to [email protected] To unsubscribe from this group, send email to [email protected] For more options, visit this group at http://groups.google.com/group/javaposse?hl=en -~----------~----~----~----~------~----~------~--~---
