CommonServiceLocatorExceptions ?

Sep 18, 2009 at 9:13 AM

Now that we have a common interface in CSL to provide standard IoC containers component and services resolutions methods, what about now having a common set of exceptions so that one can handle generically typical container resolution errors.
The use case that made me think this could be useful is where I have a class that uses metadata provided by a runtime type to perform some calculations where the calculator objects are resolved using a container, here CSL based.
The need of a known set of resolution based exceptions is so that I may need to know the container wasn't configured correctly and then take correct actions.

I alluded to missing registrations errors here but there may be others, such as circular dependencies and more.

Dec 11, 2009 at 7:40 AM

Having a common set of exceptions is especially useful when developers need to take programmatic actions based on the type of the thrown exception (e.g. using catch (SpecificException) { HandleSpecificCase(); }). To me however, configuration errors don't seem very programmatic. You'll need to go into your code or configuration file and change it manually. In that case the exception type of the thrown exception isn't that important, but the expressiveness of the exception message is. Throwing an expressive exception message is however, the job of the configured IoC container, not of the Common Service Locator, because it's impossible for the CSL to know what went wrong.

 

Jun 7, 2010 at 9:10 PM

daneel3001 brings up a great point and one that just ran me aground. The CommonServiceLocator is supposed to be common, i.e. I shouldn't have to know or handle implementation-specific exceptions. The interface doesn't specify the correct handling of no resolution, and the containers handle that differently. For example, Unity returns null for a missing registration while StructureMap throws a StructureMapException. The adapters I've used all currently just wrap the caller. They should be doing something similar (hence the common) but don't.

So what's the right story? My vote is just to return null for resolution failures. Exceptions can be expensive, and throwing when a null is returned seems a bit silly while catching an exception and returning null seems fine. Just my 2 cents.