I’ve noticed that most exception messages don’t include instance-specific details like the value that caused the exception. They generally only tell you the “category” of the error.
For example, when attempting to serialize an object with a 3rd. party library, I got a MissingMethodException with message:
“No parameterless constructor defined for this object.”
In many cases this is enough, but often (typically during development) a message like
“No parameterless constructor defined for this object of type ‘Foo’.”
can save a lot of time by directing you straight to the cause of the error.
InvalidArgumentException is another example: it usually tells you the name of the argument but not its value.
This seems to be the case for most framework-raised exceptions, but also for 3rd party libraries.
Is this done on purpose?
Is there a security implication in exposing an internal state like the “faulty” value of a variable?
Two reasons I can think of:
Firstly, maybe the parameter that threw the exception was a value that was a processed form of the one that was passed to the public interface. The value may not make sense without the expense of catching to rethrow a different exception that is going to be the same in most regards anyway.
Secondly, and more importantly, is that there can indeed be a security risk, that can be very hard to second-guess (if I’m writing a general-purpose container, I don’t know what contexts it will be used in). We don’t want “Credit-Card: 5555444455554444” appearing in an error message if we can help it.
Ultimately, just what debug information is most useful will vary according to the error anyway. If the type, method and (when possible) file and line number isn’t enough, it’s time to write some debug code that traps just what you do want to know, rather than complaining that it isn’t already trapped when next time you might want yet different information (field state of instances can be just as likely to be useful as parameters).