Re: distinguishing between failures and errors

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

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.

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.  I, for one, don't mind having
to go through and change a bunch of code because of
some refactoring I'm doing.  I can, however, see how
that's a bit of a PITA, and so you can avoid that by
using the unchecked exceptions.

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

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

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

Mindkiller?  Sure...but as long as the fear is
controlled, and you use the response productively, it
can be a good thing. ;)

-Eric

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.


--- "J. B. Rainsberger" <jbr@xxxxxxxxxxxxxxxxxxx>
wrote:
> > Hmmm...just to jump in the middle for a
> > second...personally, I dislike unchecked
> exceptions. 
> > I used to like them, because, similar to your
> > experience, you could ignore them and not have the
> > ripple effect when refactoring.  However, I've
> seen
> > this as an excuse to completely ignore the
> exception,
> > in both testing and production.  Don't like that
> at
> > all.
> 
> I agree, but at some point, you have to trust the
> people doing the work to do 
> the work. If they ignore exceptions both in tests
> and in production, then 
> perhaps you need to replace them. :)
> 
> > So, I've decided to knuckle down and NOT use
> > unchecked exceptions whenever possible.  This
> *forces*
> > you to handle them.  
> 
> I don't like the patterns that checked exceptions
> compel me to use: converted 
> exception, and so on... it all sounds like jumping
> through hoops just to 
> satisfy the compiler. My job is to make tests run,
> dammit, not to make the 
> compiler happy!
> 
> > That fact that you say using them allows the
> compiler
> > to 'get in the way' sounds like a non-issue.
> 
> "sounds like"? With respect, do you *know* that it
> is a nonissue? (If so, how 
> do I make it go away?!) For me, it *is* an issue;
> otherwise, I wouldn't feel 
> so strongly. 
> 
> I want to let exceptions propagate as much as
> possible, because exceptions 
> represent situations where my code has to throw up
> its hands and say, "Man, I 
> can't go any further." In most cases, that's
> unrecoverable within the layer 
> and I want to propagate the exception up to the
> caller. In that case, checked 
> exceptions couple the caller to callee unnecessarily
> at compile time. 
> 
> Yes, the caller needs to be aware of and handle the
> exception; however, I'm 
> not convinced that the compiler is the only way to
> achieve that. We've 
> managed quite nicely without the compiler's help and
> I'm happy with the 
> results. Again: that's what tests are for and that's
> why code is written by 
> humans and not automatically generated.
> 
> > Is this
> > coupling between your two systems?  Maybe...but I
> > (personally) would rather have it and make damn
> sure
> > those exceptions are handled.
> 
> What fear are you addressing by using checked
> exceptions? Since it is 
> possible to get along without them, you may be
> afraid of something in order 
> to want to use them. What might that be? (Please
> help me; I sound like Ron.)
> 
> --
> J. B. Rainsberger,
> President, Diaspar Software Services
> Let's write software that people understand.
> http://www.diasparsoftware.com/
> telephone: +1 416 791-8603
> 


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