I think there are two main kinds of error checking - one is validating data input by the user and the other is checking correctness of data by application components (classes, methods, etc.). In my opinion the main difference between them is that the first type of checking needs to assume that it is perfectly okay for the data to be invalid, in other words the user is allowed to enter invalid data and this doesn't cause any errors in the application - but of course the user should be informed of the error. After this first part of validation passes as successful then the rest of the system should handle the data without errors so then if a specific class is fed with invalid data it is allowed to throw an exception, halt the application, etc. In other words, a validation error at the class level should be treated as an error in the application, something to be corrected. Of course, the administrator should be notified of such errors if possible.
Personally, I tend to keep error checking of the second type to a bare minimum, otherwise I might risk cluttering all of my code with endless error checking procedures. If a class is performing some security critical task, then of course I implement as much error checking as possible but in other cases I am happy to implement only data sanitisation where needed, which is much simpler and shorter than validation. By sanitisation I mean ensuring the application doesn't crash when a class is given bad data - but it is allowed to work incorrectly.
I have found that sometimes error checking can make a task require twice as much time to code than if I could afford not to bother with errors. Especially, when a system uses or contacts third-party components, then we can expect errors at any step.