This post originated from an RSS feed registered with .NET Buzz
by Udi Dahan.
Original Post: That's so unpredictable, it's exceptional !
Feed Title: Udi Dahan - The Software Simplist
Feed URL: http://feeds.feedburner.com/UdiDahan-TheSoftwareSimplist
Feed Description: I am a software simplist. I make this beast of architecting, analysing, designing, developing, testing, managing, deploying software systems simple.
This blog is about how I do it.
The Java community has embraced my previous article "Exceptionally speaking, that is" and started delving into the finer points. One of the discussions that has started is at the Enterprise Information Technology Discussions at UT Austin and can be found here.
An interesting statement made was "This is the same reason I'm not a fan of the whole checked/unchecked thing in Java -- I don't think you can reliably predict which exceptions will or won't make sense for user code to check. (The converse problem -- having checked exceptions that I can't do anything constructive about -- happens all the time" is exactly the reason why I wrote the original post. It is important to know what is exceptional, and how to handle it, and what is wrong, and how to handle that as well.
My attempt to re-explain follows:
If you're writing infrastructure that depends on other libraries which they themselves throw exceptions, strongly typed ( as in something other than the base exceptions ) or otherwise, it is you who have to decide how to respond ( as always ). My point is that you, as the infrastructure developer, should use strongly typed exceptions to communicate to YOUR users (developers using your library) how to interact with your code.
If you get a badly formatted string, throw your own BadlyFormattedStringException - don't let the lower library's exception bubble up - catch it, its your responsibility. On top of that, expose functionality for your developer/user to check the format of string. This will enable ( some say force ) them to call your code correctly - without receiving any strongly typed exceptions.
Finally, the kinds of exceptions that you don't expect - the database blew up, communications take too long, etc.. - those YOU don't throw, the code you depend upon to run does. And, let's face it, there's nothing you can do about it anyway. That's the kind of limits you as an infrastructure developer face. Let the user of your code decide what to do with it.
In closing, I'm happy to hear the different kinds of responses appearing on both sides of the .Net and Java camps. One of the criticisms of Java has centered around forcing developers to declare the exceptions that their methods can throw. I think that this was a really good idea, to begin with, but that it assumed a high level of design skills of all developers - something that couldn't really happen. .Net has its own problems with exceptions - a developer using a library can't know what kind of exceptions could jump out and bite him without seeing the code. I just hope that the next versions of both "platforms" will learn from each other, in this respect and in many others, so that both can serve the developers better.
Previous Topic
