Re: distinguishing between failures and errors

> hehehehe....sorry you're sounding like Ron, not sure I
> can help there ;)

You could shoot me.

> Thinking about it more, I guess I'd have to agree with
> the thinking that the people working with you *should*
> know better and do the right thing.  If they don't,
> you replace them.  Unfortunately, this isn't always
> the case (at least where I've been) so I've had to
> develop some defensive coding technique.

Exactly; and so the question has to be asked: why the hell not?! Removing 
doesn't necessarily mean firing; it can mean reassigning to another 
department, changing role, and so on. I firmly believe that any seemingly 
entirely incompetent person is really just someone in the wrong role. This 
notion is reinforced at least once per project.

I need to find projects with fewer idiots. :)

> Also, from your remark about having to change code
> because of the checked versus unchecked exceptions, it
> sounded like you were merely moaning about some part
> of your body hurting.

"Doctor, it hurts when I declare which exceptions I'm going to throw..."

Using unchecked exceptions appears to pass the "doctor, it hurts..." test!

> I, for one, don't mind having
> to go through and change a bunch of code because of
> some refactoring I'm doing.

I don't consider the exception list "code". Maybe that's the reason we don't 
quite agree on this one. I see it as part of the contract, and I'm not 
accustomed to explicitly state contracts. To me, that's what the tests are 
for. If I were a heavy-duty Design by Contract guy, I might think differently.

If *all I'm changing* are method signatures, that's crappy. Period.

> Really, on the whole, I would tend to agree with you. 
> I mainly wanted to get that viewpoint out there to get
> the discussion a little broader, just in case anyone
> was thinking that the unchecked exceptions were the
> end all, be all of coding (in Java anyway).

If they follow the Wiki link, they should get ample helpings of both sides of 
the issue. :)

> Fear (of my crappy code and/or design) makes me write
> tests.

Me, too.

> Fear (of my coworkers or even sometimes of myself)
> makes me tend to use checked versus unchecked
> exceptions.

Fear of wasting my time makes me tend to use unchecked versus checked 
exceptions. :)
 
> Mindkiller?  Sure...but as long as the fear is
> controlled, and you use the response productively, it
> can be a good thing. ;)

Fear is good, but only in moderation.
 
> P.S. Ah, something else I just thought of after
> re-reading.  We are also using exceptions for flow
> control on occasion (for the web-based app we're
> converting from VB).  In those instances, the
> exception is thrown and we absolutely must notify the
> user and/or do something about it to recover.

I can see where a compile test for that situation would seem better than a 
runtime test, but I think I prefer the runtime tests, all things being equal.

--
J. B. Rainsberger,
President, Diaspar Software Services
Let's write software that people understand.
http://www.diasparsoftware.com/
telephone: +1 416 791-8603