When creating a library, must I ensure that the private methods must work as expected when called not by other methods of the same class, but by another library through reflection?

For example, if a private method private DoSomething(int number) expects that:

  • number is a positive non-zero integer, and:
  • a private variable string abc is not null and not an empty string,

and completely, ugly fails if those two conditions are not matched, must I handle those failures even if I know that all methods in the class will always¹ assign a non-empty value to abc before calling DoSomething, and pass a positive non-zero integer to this method?

In other words, is the code which is not protected against unsafe calls through reflection can be considered as low quality code, or it belongs to the caller who uses reflection to ensure that the call does not break anything?

Note: my question covers only a standard set of libraries. This does not cover code which must be highly secure (i.e. when somebody may be interested by using reflection in order to make it behave unexpectedly or crash).

¹ Because the class is correctly documented, because there are enough unit tests to be sure that any other developer will not break this method, etc.

  • will derived classes be able to call the private methods?
    – Rommudoh
    Commented Aug 16, 2011 at 7:12

3 Answers 3


By marking your method private you established your intentions and a contract. By using reflection a client code can choose to break with this contract and consequently will have to bear the consequences. The same thing happens with protocols, for things to work rules must be followed or bad things will happen.

The same problem may occur with other languages such as C++ where I saw things like

#define private public

In summary - you are NOT required to deal with these situations, the caller should know better.

  • 3
    I've seen people cast classes to (unsigned char *), and write directly to the memory offset of a member variable they want to change. My eyes bled.
    – Shawn D.
    Commented Aug 16, 2011 at 3:24
  • 6
    I would add that it is essentially impossible to protect your class against dangerous privileged code. If you somehow manage to protect yourself against inappropriate use of reflection then somebody will find a different way to ruin your day, possibly by simply overwriting your process memory directly. Defensive coding eventually reaches a point of diminishing returns, and reflection is way past that point.
    – Aaronaught
    Commented Aug 16, 2011 at 3:45

If anybody is using reflection to call your private methods, it's a sign that someone is doing something wrong. Either he's using the code in ways it wasn't designed for, or you're hiding too much of the internal workings and dumbing down the API.

But it sounds like you're not even at that stage yet, and are just trying to be pre-emptive. So my opinion is: don't worry about it. A private method should be considered off-limits; if someone deliberately violates those limits, then it's their problem if things blow up.


Well, it's always a good idea to validate non-local variables before you use them, but other than that I wouldn't worry about it. As the others said, you've established your intentions by making the method private in the first place; anyone calling it from outside your class has zero guarantees. When working in Java, I don't even put javadoc comments on my private methods, because I don't want other developers to even know that they're there.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

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