Talk:Exception handling

From ClassDBI

Ahem...is this *really* a problem? Actually, throwing exceptions instead of the old-fashioned method of returning 'undef' is considered 'Best Practise', and for good reason. Remember, constraints should be implemented to 'ensure data integrity'. If you return 'undef', then *every* time you call create/update you need to check the return value. Now, are you going to remember to do that every time you call create/update? What happens if somewhere else in your code you depend/assume data integrity, but you've not caught the 'undef'.

Throwing exceptions is the correct way to do it, IMO, and your app should catch them and deal with them (fixing the 'invalid age' in your example for instance). This is where using a test driven approach and having good test coverage is crucial. Then you'd see an exception being thrown without being caught, and deal with it before you get a data inconsistency and the problem going live. If you simply return an undef, you'd never know until it was too late.

Have a look at the argument at http://www.perl.com/pub/a/2005/07/14/bestpractices.html?page=6.