Reference
From The Pragmatic Programmer:
We believe that exceptions should rarely be used as part of a program's normal flow; exceptions should be reserved for unexpected events. Assume that an uncaught exception will terminate your program and ask yourself, "Will this code still run if I remove all the exception handlers?" If the answer is "no," then maybe exceptions are being used in nonexceptional circumstances.
They go on to examine the example of opening a file for reading, and the file doesn't exist - should that raise an exception?
If the file should have been there, then an exception is warranted. [...] On the other hand, if you have no idea whether the file should exist or not, then it doesn't seem exceptional if you can't find it, and an error return is appropriate.
Later, they discuss why they chose this approach:
[A]n exception represents an immediate, nonlocal transfer of control - it's a kind of cascading
goto. Programs that use exceptions as part of their normal processing suffer from all the readability and maintainability problems of classic spaghetti code. These programs break encapsulation: routines and their callers are more tightly couplecoupled via exception handling.
Regarding your situation
Your question boils down to "Should validation errors raise exceptions?" The answer is that it depends on where the validation is happening.
If the method in question is within a section of the code where it is assumed that input data has already been validated, invalid input data should raise an exception; if the code is designed such that this method will receive the exact input entered by a user, invalid data is to be expected, and an exception should not be raised.