Re: distinguishing between failures and errors

[NOTE: Some inline comments among the quotes.]

Kewl...I see your point, and would be happy to shoot
you should the need arise.

Argh...I have GOT to take some time to go read that
wiki stuff.


--- "J. B. Rainsberger" <jbr@xxxxxxxxxxxxxxxxxxx>
wrote:
> > 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. :)

AGREED! :)


> 
> > 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.

Ah, that could be.  Not sure what camp I fall in to at
the moment...(more reading?  screw that, I'm going to
go code some tests..hahah)

> 
> 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
> 


-Eric

__________________________________________________
Do You Yahoo!?
Yahoo! - Official partner of 2002 FIFA World Cup
http://fifaworldcup.yahoo.com