Use of checked exceptions
mnylen opened this issue · 2 comments
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.
Agree with everything here. I just upgraded to the latest version of the library and I'm going through the process of adding try/catch blocks everywhere even though my namespace and metric names are hardcoded and I already know they're valid. I think, in the vast majority of cases, something like a namespace is not going to be dynamic and it doesn't make sense to force clients to have a code path dedicated to dealing with an invalid one.
Thanks for sharing your feedback on this. New change is merged and published.