Originally Posted by xCav8r
At the risk of sounding argumentative but only wanting to get a discussion going where we can learn from one another, I'll say I agree that good programming means anticipating as many possibilities as can be imagined and handling them in the body of your code so that they don't become errors, but I also recognize that you can't always get the sort of information that you want by testing conditions. To avoid duplicating a menu item, for example, I might attempt to delete it (in case it already exists) before trying to add it. Along that line, it seems to me that there will always be a need for handling specific errors--and that sort of thing is best when handled at the procedure level. I haven't disagreed with that concept in this thread.
Those things said, despite how much I try, it's irresponsible to assume that I've planned for every possibility. When I'm working with complex projects, especially when that's in a team environment, the potential for unanticipiated errors increases dramatically. In such cases, I think a global error handler is essential. First, it provides a means of documenting unhandled errors during the development process that acts as a convenient list of issues to address before unleashing your project on your users. Second, if done appropriately, it facilitates troubleshooting down the road.
Frankly, I'm surprised that there hasn't been more of an interest from the more experienced programmers on this forum. That might be the result of my own ignorance, but this seems like one of those best practice discussions that could be of benefit to all.