I have public method add(String)
that calls private method inspectSequence(String)
to check whether String valid or not.
This method returns array if passed String
is valid, if it's invalid then method throws IllegalArgumentException
the code is next
public void add(String sequence) throws IllegalArgumentException{
inspectSequence(sequence);
}
private int[] inspectSequence(String sequence){
int[] array;
//some actions
if(<some condition>) throw new IllegalArgumentException("description");
return array;
}
So in cases, when invalid String
were passed to add
method output will be next:
java.lang.IllegalArgumentException: description
at inspectSequence
at add
But I don't want user to know about private inspectSequence
method because this is realization detail, right?
So what I can do in that case? Is it a good idea to throw unchecked exception here?
And is a good idea to throw exception inside inspectSequence
method or I should return null
when supplied String
isn't valid and then check returned result in add
method and depending on it throw or not throw exception?
I'd say no. It's true that you don't want the user (which in that context means someone calling the code) to "know" about internal methods like
inspectSequence()
. With "know" I mean be able to call, depend upon etc.Knowing that the exception might be thrown and under what circumstances is something that a caller should know about, knowing where exactly it is thrown isn't necessary but wouldn't hurt.
Of course you could catch that exception in the calling method and throw another one but that would just lose information and might make the code harder to debug/maintain since the information where the input was not accepted would be lost to the caller.
That depends on whether that exception should be handled at runtime or be fixed.
Suppose the caller needs to know that the sequence was invalid and should handle that information appropriately, e.g. display some information to the enduser. In that case it would be better to throw a checked exception that describes that case.
On the other hand, if the input violates the contract of the method, i.e. the input sequence should never be invalid (or otherwise it's a programming error) then an
IllegalArgumentException
would be ok - situations like passing null to a method that doesn't expect null parameters.I'd say no. Returning null and then handling that in the calling method might be a reasonable way in some cases (e.g. if you have different callers that handle null differently) but your case is none of those. It would make code more complex and thus harder to read and maintain, especially since null might have multiple meanings which you'd have to define in that case.