[crazygringo]

I totally disagree. These are all the same:

    Is the network up? / Is the connection to SQL up? / Did someone just turn off the SQL machine half way through the query? / Can we find the server?

These are not errors, just normal business logic that has to be handled:

    Are there any rows? / Did you return a Null when I was expecting a value?

These are not runtime errors, they're just debugging during development (with possible exception of overflow, depending on context):

    Did the SQL compile? / Do I have rights on this table? / Did you return a float when I was expecting an int? / Did my value just overflow? / Did you just return 0 and I tried to use it in division?

And likewise, these all just have to do with the design of your program, which you either know you have to deal with or not:

    Have you just terminated me as a result of a deadlock? /  Did I just try to access the session but some other idiot clear it? / Did I just try to call a method on an object that is in fact null?

I already said that you may not have to worry about things like memory allocation errors, depending on your needs. Most of the stuff listed above is either redundant, or has more to do with the design of your program. I stand by my point that, in most programming (say, back-end web stuff), you're handling more like 5 errors per 20 lines, not 50 per 20.

And that, yes, those 5 (or however many) errors should be planned for from the start.