Use of checked exceptions #140
Description
Hello,
Just wondering, what is the reasoning behind this library starting to throw checked exceptions in the newer versions? Makes it quite verbose to use the newer versions of the library versus what it was with the older ones. For example, setNamespace throws InvalidNamespaceException and putMetric throws InvalidMetricException. As these are checked exceptions, one must wrap every call to these in try..catch, or make these the caller's problem.
If one of these is thrown, what can my code realistically do to handle it? It's not like I'm going to be able to fix a metric name on the fly, when in most cases it is hard coded. In vast majority of the cases, the only option is to propagate the exception up, as it's a programming error when these exceptions would be thrown. They result from incorrect usage of the API, and are not something that can be handled in a meaningful way.
Imagine how your code would look like if the Java standard IllegalArgumentException was a checked exception. Speaking of, that would be a perfect exception base class for these kinds of exceptions...
And one case where it doesn't make any sense to use checked exceptions... Calling DimensionSet.of() says it can throw DimensionSetExceededException, but in reality, it's impossible for it to throw that, because one can't make a DimensionSet with more than 30 dimensions using the of method. But still the library makes me handle this exception that can never happen.