Handling exceptions may not be exciting, but it’s a crucial part of writing your application. Instead of putting it off until the “fun stuff” is done, Jeff Langr advises a head-on approach: Drive exceptions through tests, like any other production code.
Crafting Java with Test-Driven Dev: Handling Exceptions
About The Author
Eugenia Loli
Ex-programmer, ex-editor in chief at OSNews.com, now a visual artist/filmmaker.
Follow me on Twitter @EugeniaLoli
Howdy
Interesting article, using exceptions this way doesn`t sit very well with me.
IMHO returning NULL is more then appropriate if you try to get a card from a deck that is empty, NULL simply means does not exist or unknown.
It is expected behavour to eventually run out of cards (no exceptional set of circumstances) so indeed checking that there is a card at each step seems reasonable and blindly taking cards untill the deck smacks you in the head to stop does not.
To me an exception would be if the entire deck went missing before all cards were delt or maybe angry little people stopped you taking cards even though there were more in the deck.
I guess this is more about assignment of responsibility, should we code super smart data structures or teach the users how to use simple things properly.
If anyone can point me to other simmilar articles as to why they`ve taken this approach I`d love to read them.
Well, if you’re working with a java.util.List and reference index #2 in an empty collection, what happens? Again, I’m assuming you’re accessing this index outside of a loop. But I agree, it is expected that we will run out of cards and this is where a loop or Iterator helps prevent such exceptions. A better example might have been something involving netwroked code where exceptional conditions are more common
Basically what he’s saying is that if your code throws an exception on a given condition, you should test that condition to make sure the exception is properly thrown when the condition is encountered. I find this to be a good practice, but only when my code needs to throw an exception.
Ryan-
And this case is another one of them.
Code unit-tests should do one thing — test _expected_ behavior for known good cases. In user-oriented code, there should be validators running to verify the integrity of the data being manipulated before it’s operated upon. Test those, too — with known data sets for expected behavior. If you need to test for an exception in some instance (which is very common, as exceptions are excellent methods of flow control for conditional branching when used properly if the data is in an unexpected format or a result is outside of a predefined acceptable range)
I also agree with the above posters. In some cases, it’ll be desirable to return null, and have to manually check for it. 99% of the time though, unchecked NullPointerExceptions are the preferred manner of vomiting on collection access — except in the case of looping an iterator.
I’ve found the jMock approach to unit tests to be insanely helpfull — Only test what you need to, and only if you can guarantee the test is accurate for the use case you’ve got. Don’t try to break your code, verify it.
Testing should also be done on unexpected data. While in theory unexpected data should never rise, in real life there can and will be instances that unexpected occurances will happen. If a program can crash your system or cause other serious flaws with unexpected data you can be assured that malicious users will try to exploit that weakness.
Well, yes, for most code you generally want to be testing for correct behavior in the valid data range, but at the same time it’s not a bad idea to ensure that your code behaves sanely (if not necessarily correctly) outside of said range. I mean, if you’re sure you have validity checks in place for every possible code path leading to the code being tested, then all well and good, but that’s frequently difficult to ascertain in a more complex system.
Browser: Mozilla/5.0 (Danger hiptop 2.0; U; AvantGo 3.2)
To simulate exceptions for Windows or .NET applications, consider using a fault-injection product such as Holodeck:
“Holodeck is a unique testing tool that uses fault simulation to emulate real-world application and system errors.”
http://www.securityinnovation.com/holodeck/index.shtml
Enjoy!