Subject: Re: distinguishing between failures and errors - msg#00118

List: java.junit.user

Date: Prev Next Index Thread: Prev Next Index

> 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

Was this page helpful?

Thread at a glance:

Previous Message by Date: click to view message preview

Re: distinguishing between failures and errors

> That fact that you say using them allows the compiler > to 'get in the way' sounds like a non-issue. Is this > coupling between your two systems? Maybe...but I > (personally) would rather have it and make damn sure > those exceptions are handled. If the problem is coupling, counldn't that be solved by throwing java.lang.Exception? My guess is that whichever approach you choose, you still document the exceptions that get thrown, right? So the only thing you gain with the suggestion above is forcing the code to be aware of the Exception possibility of your code. Manuel Amago.

Next Message by Date: click to view message preview

Re: Re: distinguishing between failures and errors

> > That fact that you say using them allows the compiler > > to 'get in the way' sounds like a non-issue. Is this > > coupling between your two systems? Maybe...but I > > (personally) would rather have it and make damn sure > > those exceptions are handled. > > If the problem is coupling, counldn't that be solved by throwing > java.lang.Exception? That leads to excessive, gratuitous duplication! > My guess is that whichever approach you choose, you still document > the exceptions that get thrown, right? Yes: it just depends who the intended audience includes. Mine does not include the compiler. None of its business! :) > So the only thing you gain > with the suggestion above is forcing the code to be aware of the > Exception possibility of your code. Yes: I submit that that is what tests are for. (If you're here, then you're writing tests, after all.) -- J. B. Rainsberger, President, Diaspar Software Services Let's write software that people understand. http://www.diasparsoftware.com/ telephone: +1 416 791-8603

Previous Message by Thread: click to view message preview

Next Message by Thread: click to view message preview

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

Loading Comments...