The main decision criteria are likelihood and recoverability. If the error isn't recoverable (maybe it leads to data corruption, say), then you generally have

The main decision criteria are likelihood and recoverability. If the error isn't recoverable (maybe it leads to data corruption, say), then you generally have to really batten down all your hatches and fix and/or test everything you can, even if it doubles or triples the overall effort. Generally, if you're shipping the software instead of doing SaaS stuff, fewer things are "recoverable" than if you control everything yourself and can quickly patch things (either patch the code or patch the data) to work around edge cases that come up infrequently. Non-recoverable edge conditions generally need to get fixed regardless of their likelihood; as issues get easier to recover from, the likelihood of them occurring needs to be higher in order for them to be worth addressing, relative of other things. And of course, you also need to factor in the expectations of your customers, which will be highest if they're buying the product to use themselves and lowest if they're using a free service you provide. If you haven't realized it already, you'll eventually realize that finding and patching and testing all the edge cases is incredibly laborious and really is usually the "hard" part of development (the happy-path cases are usually the easy part), and secondly that prioritization is the key to productivity. There's an art to knowing what will come back to bite you, what's recoverable, how bad it'll be, when to bullet-proof and when to move on to the next thing.