Take the 2-minute tour ×
Programmers Stack Exchange is a question and answer site for professional programmers interested in conceptual questions about software development. It's 100% free, no registration required.

I was just reviewing some code I wrote a while back, and can see that I have a couple of private methods that throw argumentnullexceptions and/or argumentexceptions if there are issues with the methods parameters.

I guess my rationale is that helps future proof the application if someone attempts to "misuse" the method in future. However, given it is a private method and the people who are likely to call this method can see the associated comments and code, it is just unnecessary to throw this. It certainly doesn't hurt to have them, although it does add clutter.

My feeling is that these exceptions are generally more useful on something like a API that is going to be exposed publically.

share|improve this question
add comment

4 Answers

up vote 16 down vote accepted

Normally, for private methods you do not throw exceptions since as you wrote it, the developer is supposed to know how and where he is calling the method from. As such, the variables passed as parameters to the private method should be checked outside of the method, that is, before calling it. Throwing "InvalidArgumentException" and other such exceptions is considered good practice for public methods (whether you are writing an "API" or not).

For those cases where you want to throw "InvalidArgumentException" it's worth mentioning that there is an Assert class in the Spring API for Java since version 1.1.2. It has been very helpful - to me at least - in writing less code to perform checks.

You may however use "asserts" to check parameters in private methods. That is one of their true purpose. They are more reasons to use them, check out the following link which also explains thoroughly when to use asserts and when to use exceptions. Asserts are not to be included in production code and the compiler removes them by default. So they are what you are looking for: helping the developers, invisible for the users. In Java you have to use a special flag ("-ea") to tell the compiler to enable assertions. You may consider them as "debugging" friends.

Here is how to use asserts in:

share|improve this answer
add comment

Like everything else it depends....

If the public methods are simple wrappers that call the private method (along the lines of a private overloaded method) then it may make sense to throw an exception in the private method instead of checking in each public one.

Generally if it doesn't meet the above definition then I wouldn't usually check the arguments / throw an exception on a private method. Although there are other cases I generally do this in a private method prior to performing some expensive operation that could fail part way through if the arguments are invalid.

share|improve this answer
add comment

Consider the following structure:

  1. internal logic: This function assumes to be called with correct parameters and therefor uses asserts to verify preconditions, postconditions and invariants to check your inner logic.

  2. User interface wrapper: This function wraps the internal function and uses InvalidArgumentExceptions to handle wrong values and to tell the user to correct his inputs: Assert(x).hasLength(4), Assume(y).isAlphanumeric(), Assert(z).isZipCode(); Assume(mailAdress).matchesRegex(regex_MailAdress); Reject(x).ifEmpty();

  3. Batch interface wrapper: This function wraps the internal function and uses logging, validity markings and statistics to handle wrong values without interrupting some long-running task. The markings could be used later by someone checking and cleaning the result-database.

  4. Command line interface wrapper: this function wraps the internal function and asks again for the last input.

You should use both - asserts and exceptions - in different methods for different tasks. You should separate internal logic from parameter checking. Compare it to the separation of Model, View, Controller.

share|improve this answer
add comment

There are better ways to avoid null reference check: use code contract or an AOP framework to do the check for you. Google "c# code contract" or "postsharp".

share|improve this answer
    
I guess my question would extend to code contracts also. Is there a need for checking method preconditions in a private method (ie. for future proofing, or stopping you from shooting yourself in the foot)? –  Mr Moose Aug 11 '11 at 6:51
add comment

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.