After reading Mitch’s discussion on throwing Exceptions and quickly refreshing my brain as to what the official Microsoft position is, I went away and was rethinking how I determine if/when I’m going to throw an exception.
I started off with the following concepts:
– An exception should be thrown when a method/operation cannot be completed successfully.
– Exceptions should no be used for application flow control.
– Return values should not be used to indicate if a method/operation has been completed successfully
Now I must say that I agree with all of these. However there is one concept that I definitely think has merit, which is:
– An additional set of functionality should be provided to allow a developer to query whether a method/operation will be successful if called (eg “CanConnect” to be called prior to an attempt to call “Connect”).
This last concept does cause me some concern though. The main reason that you would want this functionality is to reduce the number of exceptions that are used for application flow control (see concept above) – for example in the case of the Connect method you would use a condition based on the CanConnect method to determine if Connect should be called. So, what are the downsides:
– Firstly, I see having these guards might lead to sloppy programming where exceptions don’t get managed. For example, just because I have called CanConnect, doesn’t mean that Connect won’t fail. If it does and an exception is thrown, I still need to handle it!
– Secondly, the query functionality may increase the time taken to call the method. For example the CanConnect method might take as long as a call to Connect, in which case if this is routinely called everytime you need to connect it may well negatively affect performance. I guess there is a trade off here the again has to be managed.
My last thought regarding exceptions is that I still believe that .NET is missing a feature that I loved/hated in Java (and yes for my sins I did do a bit of Java programming way back when it was all the rage). This feature is the way that methods specify which exceptions may be thrown. The reason I say loved/hated is that I loved it when I was building robust code, as it forced me to think about how I was using that method and whether I had handled the different responses (including exceptions) from the method.
I hated this feature for two reasons. Firstly, that it was a pain cause the compiler insisted that I rethrow exceptions that I didn’t handle in my code (for example if I used a method that could throw an IOException I either had to catch this or specify that my method could also throw this exception) – why can’t the compiler be sensible and deduce this for me, after all when I use that method it’s not that I look at the method itself to work out what exceptions are thrown, that’s again the compilers job (or intellisense – does Java have that now??). The second reason is that some developers are sloppy and just say that every method could throw Exception – kind of defeats the purpose of having this feature, right!!
Now it would appear that we may have missed the boat as it would be too difficult to go back and force every .NET method to specify which exceptions are thrown. However, this is an area where tool support might provide a good compromise. Now that both C# and VB.NET support rich xml commenting it may be an opportunity to really make use of this functionality. By specifying in the comments which exceptions a method may throw, this could be used by the IDE to warn developers if they haven’t handled theses exceptions when a method call is made. As with most othe IDE support this could be an option that can be configured by the developer or dev team according to their preferences.