|
|
|
|
|
by iramiller
5526 days ago
|
|
Some clarification seems to be required since I am being voted into oblivion (perhaps never ever use ever or never?:) ) When writing some code that relies on a method in a specific class or interface being present then actively test for it and react appropriately. Writing the code based on how it is hoped the program state will be and letting the exceptions fall out is what I mean by exception driven development. In many cases this is a code smell that indicates a section that was not completely thought out. The next step with an invalid cast exception or a type check is to take action and do something about it. When faced with an exception there can be more ambiguity about it's source especially when there are many lines in the try block or if you are calling into other libraries. What if there is some code in the save method that throws the exception for type casting and the invalid cast exception assumes that the source is the base class problem? Now you can add further debug time to the cost of trying to short circuit the type check that was intended up front. |
|