Exception handling design issue

Question

I have a class that's a low level building block of my application. It takes as its single constructor argument a String that needs to be in a known format. At present the constructor takes this String and checks it, throwing an Exception if it's not in the expected format. Given that the String can be built up from user sourced data, this check is absolutely required.
The problem is that 95% of the time I build these objects using well known Strings - frequently constants from my code. In these cases I don't need the check. That's not really the issue - the checks don't cost a great deal. The problem is the Exception: each time I want to create one of these objects I have to handle the exception I know is never going to happen. I now have dozens of try/catch's in my code that just wrap a call to the constructor and have an empty catch block because I know that's never going to go wrong and I just want to shut the complier up.
This can't be the right way to do it! I don't want to take out the String check entirely, and I do need the safety net of the Exception in some cases, but without the hassle it provides so much of the time. How should I change the design of this class so that I get the balance I want?

Answer 1

new Foo(Bar.DEFAULT_BAR_1); //without try-catch
//or
new Foo(new Bar("blublab")); //requires try-catchHmm, maybe I haven't quite got this sussed yet.
The nature of my String value is a location - like a URI. My application is full of them. A good number of them are known at compile time and can be defined and used as constants by the code that needs them, but the underlying class needs to be able deal with user supplied strings as well.
I define a class called Location which used to have a single constructor that took a String. If the String was of the wrong format it threw an Exception, but in most cases I know what I'm passing and I know it's valid. That makes the Exception, and associated try/catch, redundant 95% of the time.
So I added another constructor: the original still takes a String and throws the exception, and the new one takes a String and a dontCheck flag and doesn't throw anything. This new constructor doesn't do the format check - things will go wrong if an invalid String is passed into this constructor. In principle this works as long as I stick to the rule - only use the constructor with the dontCheck flag when I know the String I'm passing is valid. But it feels like a bug waiting to happen.
If I understood correctly, your suggestion was to create a new class - let's call it ValidatedPath. Now I can change my Location's constructors:
public Location( ValidatedPath trustedPath )
public Location( String untrustedPath ) throws LocationException
...This looks good - I can't create a ValidatedPath without getting an error, so that Location constructor doesn't need to throw anything.
But hang on - all I've done is move the problem back a step. When I create a ValidatedPath from a constant, I still need to handle the exception the ValidatedPath constructor will throw if it's given an invalid path:
public static final String goodPath = "THIS:IS:A:GOOD:VALUE";
ValidatedPath vp = new ValidatedPath( goodPath );   // I now need to handle the potential exception here...
Location l = new Location(vp);   // ...instead of hereIn the above snippet, goodPath is a valid, constant path. But when I use it as an argument to the ValidatedPath constructor I still need to wrap the call in a try/catch because the ValidatedPath constructor still needs to be able to throw an Exception if the argument is invalid. I haven't really achieved anything.
Puzzlement continues. I'm just looking at your use of the IllegalArgumentException, as also suggested by others. I think I need to understand this concept of "unchecked" properly - maybe that's the key.