> The last thing he mentioned was
> that he often sees bugs coming from not handling errors.
> So regardless of whether or not people who read this site
> know about handling error conditions, in his experience
> that's a main source of bugs.

And I see the same thing. I guess what I'm trying to say is that the kind of people that haven't figured out that error handling is important aren't really the kind that make a point to go out and read articles about how to write good code. Maybe there's a few that will but it seems a little bit like writing an article about how the protecting the environment is important for a Sierra Club member newsletter.

There are two things that annoy me to no end. Developers that ignore exceptions and/or error codes and developers that throw exceptions or return error codes for things that are no errors. The first forces me to have to tell people to always check for errors and never squash exceptions and the second forces me to make exceptions to that rule.

> > I guess this seems so obvious that I don't really
> > understand why it would be posted here. I don't think
> > many of the people that check out this site don't
> already
> > know this. Am I wrong?
> >
> > One of my favorite lines is to the effect of "any
> donkey
> > write a program that works when everything goes
> perfectly.
> > The trick is dealing with problems effectively."
> >
> > The people that need to understand this are the
> managers
> > that reward those who don't worry about anything but
> the
> > 'happy path' because they seem efficient.
>
> I basically agree with what you are saying, but I think
> there are situations where sticking close to the happy
> path is appropriate. For example, prototyping when you
> really have no requirements. You are using the code as a
> vehicle for flushing out requirements, and at that point
> being cheap, malleable, and disposable are more important
> than being robust.

Of course. I didn't mean to imply such situations don't exist.

> The problem, of course, is the manager who, in a stroke of
> brilliance, decides that a mockup intended for flushing
> out requirements somehow represents "almost done" software.

This is bad but I see scenarios where ostensibly expert developers deliver code as complete with major holes in their error handling, if there even is any. Often they are rewarded for doing so. When someone else comes along to fix things, they are often compared negatively to the original developer because they took so long to work on something that the original person completed so quickly. The manager draws the conclusion that the cowboy is much more efficient.

A lot of this comes down to managers that have not written code or were themselves the kind of developer that couldn't be bothered with error handling but mostly the former.