I have learned through much pain that the most fun, comfortable way to program actually anything, is to deal with all errors when starting a new thing. Design how you're going to indicate errors (exceptions? return values? if so, as a struct, or as an enum?). Deal with incorrect inputs by returning errors. Then write tests checking all of those errors are being detected. And then start writing the substantive code. Then you have guaranteed-good inputs for the actual program/function, which is surprisingly nice. Any other approach is more painful and takes longer.

An unexpected (for me) illustration of this approach's value was very recent, when I was using the newly-incorporated Test::PDL to update all the tests of PDL to use is_pdl, which checks types, dimension, bad value patterns, NaNs, numerical values, and reports in some detail any failures. The tests thus modified are SO much simpler, with no need for extra code to dump any incorrect inputs, and have actually caught at least one bug (incorrect handling of converting a negative floating-point number into an unsigned value - on ARM, it gets a 0, even though on Intel it gets the INT_MAX+number+1).