On 2/12/14, 9:50 AM, David M. Lloyd wrote:
Finally, one small matter I want to sort out is that we have several
modules which use a project-specific code for IllegalArugmentExceptions
that pertain specifically to null parameters, whereas some do not use a
code for this case and just throw the exception.
My feeling is we should either (a) don't use a code for this kind of
thing, or (b) come up with a "common" module or code space+project code
which every project can reuse, so we just have one code that universally
means "the parameter can't be null".
I think there are 3 cases:
1) Validating input that isn't coming from some external source. Use an
assert, no i18n. CI testing should catch code that violates your
constraint. An IAE is ok too, but when I review code, "assert" tells me
that a deliberate choice was made that i18n is not a concern, whereas an
IAE with no i18n looks like something that needs fixing.
2) Input is coming from an external source, but there's no expectation
of added value to the user from using a context specific exception
message. Value for example being a better knowledge base article or
google search result. The stack trace provides the relevant data. Go
with your b) solution.
3) Cases where there is some value from a context specific exception
message. User can use the code to find content that better explains how
the problem happens and how to avoid it.
Senior Principal Software Engineer
JBoss by Red Hat