Simulate the failure / exceptional situation.
Your mock objects are crash test dummies and you already know what can possibly go wrong, it shouldn't be hard to emulate it (you know because you've already prepared for it, if you don't, well, you'll soon find out ;). And... it's always amazingly fun to physically unplug your database server while your processes are running. Doesn't really scale as a testing method, but it's awesome even if you do it just once.
Consider this trivial / overly simplistic example:
Class A does something, and throws an
OMGSomethingBroke exception if something goes awry.
Class B calls
Class A, and in case something breaks, catches the exception and logs it (or whatever).
What you need to do is create a mock of
Class A, let's call it
Mock A that does nothing more than throw the
Mock A and
Class A should implement the same interface, and that's about it. You've emulated the failure, and you can now move on to testing
Class B. Have it call
Mock A instead of
Class A, and test if it handles the failure gracefully.
Testing can be exceptionally simple if your design is solid (yes, both puns intended).
Just found a very interesting Udacity course, Software Testing (CS258) - How to Make Software Fail:
When writing software, destruction can be just as valuable as creation. Learn how to catch bugs and break software as you discover different testing methods that will help you build better software.
The course has a wider scope than your question, obviously, but the core message in its summary applies: Breaking stuff is fun! (Well, and a good way to test software).