It's not one error handler.
Every time you write code that might go wrong, your dbs needs to pick up the error. but more importantly deal with it.
It's not enough to just know that there is an error. Some errors don't matter (but still need to be intercepted, and handled). Others are much more important. So possibly every individual sub or function needs a error handler. It's not quite as bad as that, but some development tools will automatically insert an error handler framework in every sub or function.
For instance, every time you divide two numbers you ought to have an error handler in case the divisor is zero.
Arithmetical operations might give you an overflow error. You need to manage this. You might need to change a data type in your dbs, or you might just report that a number is too big, and then either carry on, or cancel the process.
A file or folder you expect to be in the system may not be there, or may already be there. Virtually every time you have any interaction with files (i/o) you need an error handler.
for example, the only way you can test whether a certain field exists in a table is to test for it. If the test fails, you get an error which you need to handle and then continue appropriately.
Do you ever get situations where your code errors, informs you of a problem, and jumps into the code? That's an unhandled error, and you don't want users to ever see code. In fact, you may want to distribute a .accde verson of the database, so they just cannot change your dbs design. If you do that and there is an error, you will be getting phone calls just saying "my database isn't working", as the dbs reacts slightly differently in an .accde.
The error messages you get in access just give you text. They don't give you an error number. Sometimes the error number is really helpful, so you often add your own error handler to present the error in a different way, and it becomes a helpful designed message rather than a standard and less helpful access message.
Some "errors" aren't even errors, but do affect your programme. If you try to insert a new record, but it's already there, it's not a programming error, and it's not directly trappable. It's called a form error, and you can add form error handlers to manage these types of errors.
A lot of code is defensive. Error handlers, input validation, input sense-checking, ensuring some fields can't be blank/null and so on. So it's more than error handling - it's everything to make the dbs robust.
