Overriden method doesn't throw Exception, super may.

[Chris Smith]

Dude, what's your prob?

I snipped your comments because they wrapped badly in my newsreader to
the point of being unreadable in the reply anyway, and I didn't want to
fix them. I admit that was a little lazy on my part, but I guarantee
you that it's not because I ignored them. Your comments said you don't
like ignoring the exception, but that you think it's cleaner than
writing a catch block to wrap in RuntimeException; that's exactly what I
was referring to.

I'm sorry if you're offended by my posts here. I see your advocacy of
ignoring exceptions as being extremely dangerous, and I'd like to
prevent people from taking that advice if at all possible. I have
nothing against you, but I do think (tempted to say *know*) that you're
mistaken on this point in a way that could have dire consequences.

I will restate the comment that, if you think there is the possibility that
MyException will be thrown, you cannot ignore it, and converting it to a
runtime exception is just as bad.

The problem, I think, is that we have differing definitions of
"possibility that MyException will be thrown". I agree completely that
if there is any situation where the current code, as written locally and
according to the specified behavior of any code it calls, might throw
that exception, then you should declare it as a checked exception. My
concern is what might happen with future modifications of the code.

It may be true, now, that super.myMethod will never throw MyException
from this context, as written. Nevertheless, it's easy to imagine
someone changing something about it's implementation, resulting in the
possibility that MyException will be thrown even with an instance of
Sub. Because Super's myMethod already declares MyException, the author
of the code may conclude that change to clients is not necessary, either
because the author doesn't understand all of the compatibility issues
with inheritance, or merely because the API is not considered fully
published (i.e., it's in-house, perhaps in a different module but not
provided as a third-party; in a situation where change control is
relaxed). In that case, the RuntimeException catches the error.

I still don't understand the statement that RuntimeException is just as
bad. Throwing a RuntimeException never potentially wipes out end-user
data. That's certainly one good thing about it.

I understand that you try to make a name for
yourself here and generate some consulting fees [...]

You're really sorta sounding like a troll here. I'm giving you the
benefit of the doubt... but when you show up and post anonymously in a
newsgroup for all of five days, give horrendously dangerous advice on
exception handling that contradicts all other respected sources of
information, and then start degrading a regular who has been posting
here for seven years by implying that I have hidden motives and am
trying to "make a name" for myself; well, let's just say that the doubt
of which you're getting the benefit is dwindling fast. The instant you
threaten to killfile Dale and Roedy as well, the doubt will be gone
entirely.

For the record, I don't take consulting work. I am employed full-time,
I like my job and plan to keep it for years to come, and my job doesn't
involve hiring myself out for consulting. MindIQ (my employer) does
offer training in Java software development and I generally teach it
when it's needed unless I'm otherwise committed, but I'm not here to
promote MindIQ's training, and I've been posting here for a lot longer
than I've been training for MindIQ.

--
www.designacourse.com
The Easiest Way to Train Anyone... Anywhere.

Chris Smith - Lead Software Developer/Technical Trainer
MindIQ Corporation

 

[Tony Morris]

public void myMethod() {
YUK!
At least throw a RuntimeException is the exception that "never occurs" in
case something unforeseeable occurs - such as changing the implementation of
the interface.

Ignoring checked exceptions is a horrible practice in ALL circumstances.

 

[Chris Smith]

Ignoring checked exceptions is a horrible practice in ALL circumstances.

Just to be complete, this brings us to the (now familiar to those of us
who've been around) issue of what "ignore" means. There are cases where
you might intentionally catch an exception (say, InterruptedException
for example) and continue having already gotten the benefits of the
exception (in the example case, waking you up from a sleep or wait
method call). The point is to use a comment or something to explain why
the exception handling is properly empty, not to clutter logs and such
with exceptions that occur as a normal part of processing.

--
www.designacourse.com
The Easiest Way to Train Anyone... Anywhere.

Chris Smith - Lead Software Developer/Technical Trainer
MindIQ Corporation

 

[Java Architect]

I snipped your comments because they wrapped badly in my newsreader to
the point of being unreadable in the reply anyway, and I didn't want to
fix them. I admit that was a little lazy on my part, but I guarantee
you that it's not because I ignored them. Your comments said you don't
like ignoring the exception, but that you think it's cleaner than
writing a catch block to wrap in RuntimeException; that's exactly what I
was referring to.

That's NOT what my comment said. It said that I don't like breaking the rule
of thumb about squashing an execption, but, in this particular case, it's
not really so bad. And, the reasoning for that is that the original poster
was asking for a solution such that:

* Class A has a method (f) that throws an exception (E) only because it
relies on another member method (g) that throws E.
* B subclasses A and overrides g such that it does not throw E, and even
erases it from the signature so it CANNOT EVER throw E.
* Calls like "new B().f()" shouldn't have to handle E because it's not
possible that it is thrown.

Now, in this particular instance (which says nothing of other scenarios)
there is no danger in quashing E by overriding f inside B. I'm absolutely
not advocating generically quashing exceptions when they might occur. In
fact, the comments that you snipped also said that, if the exception is at
all possible, you absolutely mustn't quash it.

I am saying that, if the situation warrants, and a developer better be
damned sure that it is, break the rule of thumb.

I'm sorry if you're offended by my posts here. I see your advocacy of
ignoring exceptions as being extremely dangerous, and I'd like to
prevent people from taking that advice if at all possible. I have
nothing against you, but I do think (tempted to say *know*) that you're
mistaken on this point in a way that could have dire consequences.


The problem, I think, is that we have differing definitions of
"possibility that MyException will be thrown". I agree completely that
if there is any situation where the current code, as written locally and
according to the specified behavior of any code it calls, might throw
that exception, then you should declare it as a checked exception. My
concern is what might happen with future modifications of the code.

It may be true, now, that super.myMethod will never throw MyException
from this context, as written. Nevertheless, it's easy to imagine
someone changing something about it's implementation, resulting in the
possibility that MyException will be thrown even with an instance of
Sub.

That's what bugs me about you altering my original post the way you did. I
pointed this out as a possible problem and, again I say, if there is the
possibility that Sub can ever throw MyException, you cannot quash it. I add
to your argument that converting it to a RuntimeException can wreak havoc on
the unsuspecting callers just as well as quashing it.

I still don't understand the statement that RuntimeException is just as
bad. Throwing a RuntimeException never potentially wipes out end-user
data. That's certainly one good thing about it.

Use of a quality debugger to step through the code would help locate the
error in the same amount of time regardless of whether it's quashed or
converted, so both, IMHO, are just as bad.

I understand that you try to make a name for
yourself here and generate some consulting fees [...]

You're really sorta sounding like a troll here. I'm giving you the
benefit of the doubt... but when you show up and post anonymously in a
newsgroup for all of five days, give horrendously dangerous advice on
exception handling that contradicts all other respected sources of
information, and then start degrading a regular who has been posting
here for seven years by implying that I have hidden motives and am
trying to "make a name" for myself; well, let's just say that the doubt
of which you're getting the benefit is dwindling fast. The instant you
threaten to killfile Dale and Roedy as well, the doubt will be gone
entirely.

Time posting on the board is irrelevant to the merits of an argument. I
don't agree with you, you don't agree with me. Fine, make your argument
about why your solution is better based strictly on the code and
ramifications. Anything else is just red herring.

I wasn't implying that you had hidden motives. I didn't even think the
motive (if it exists) was supposed be hidden, and I don't even think there's
anything wrong with that motive at all. I've noticed Roedy Greene posting
links to his website (to pre-written answers to common questions) and think
it's a great way to get some free publicity. So, I wasn't attempting to
degrade you for that. I was chastising the act of defending something via
dubious means in an attempt to hold up a reputation. Typically, I find such
tactics to be used in cases where a person knows his argument is untennable.
If it was an honest mistake, fine.

As for posting anonymously. My e-mail address is in the header of my posts.
I check that consistently, so I don't know what your talking about. I don't
give my name? What's a name mean? I could post that my real name is Jeff
Jordan (not true btw) and it doesn't give you any information about me nor
does it affect the merits of my advice. I am posting under the same nick
every time (and I use the same nick on IRC and other boards), whether that's
"foo" or "bar" doesn't make my posting history any less traceable.

If you want some background, I'm a consultant who's been working in the
industry for 17 years. I've worked with many different languages on many
different platforms. I've been working with Java since 98 and on web-apps
since then as well (I wrote a servlet engine based on the original spec).
I've been an invited guest speaker at conferences like JavaOne. Besides
years of experience as a programmer, I've worked as a tech
lead/mentor/trainer on projects with companies like Toyota, Rolls Royce
Aerospace, SAIC, Charles Schwab and Blue Cross of California. Nowadays my
role is usually to train and mentor teams in best practices. I have a great
track record of improving teams' efficiency while lowering defect rates, so
I know I'm doing something right.

Before you go off and accuse me of trying to sell myself with this bit, I
don't take random work. I have enough contacts now that, even in this crappy
economy, I get more work offers than I can accept and at the moment can
afford the luxury of only working with prior business relationships. There,
now I'm not anonymous, as this info would allow anyone who knows my resume
to recognize who is the person behind the posts.

I started posting a few days ago because I didn't have a good book to read
and was sitting around waiting for something to happen so that I couldn't
leave my house. Had nothing better to do so I figured I'd try something new
(well something I hadn't done in a long time at least). Anyway, I'm not here
to engage in flaming. I have nothing against you personally. I didn't like
getting my post chopped and, therefore, misinterpreted. If that was a
mistake, then hatchet's buried. I'd offer my hand to shake, but, well, this
is Usenet, and digital handshakes are better left for TCP/IP

 

[Java Architect]

And, as this was example code, I didn't clutter it with putting those kinds
of comments in. The point of the example was that I wouldn't convert it to a
runtime exception. Chris, placing comments is exactly what I'd do in
production code. To use your example of the InterruptedExample as an answer
to Mr. Morris:

try { Thread.currentThread().sleep(1000); }
catch (InterruptedException err) { throw new RuntimeExcepton(err); }

This would probably be one of those cases that doesn't fall under ALL
circumstances. Or, Mr. Morris, do you ALWAYS do this?

However, Chris, I'd like to point out that this is the unfortunate effect of
your inacurrate edit of my original post. Someone else has taken my post,
out of context and slammed it for reasons that I already answered in the
stuff you cut.

 

[Chris Smith]

That's NOT what my comment said. It said that I don't like breaking the rule
of thumb about squashing an execption, but, in this particular case, it's
not really so bad.

Isn't that a restatement of what I just said? It's the "not so bad"
that bothers me, and the part about throwing a RuntimeException being
just as bad as ignoring the exception. I don't see how aborting with a
descriptive error message can ever be considered just as bad as
continuing and ignoring a code failure. Ignoring failures is dangerous.
Throwing a RuntimeException will only stop code from working.

(Of course, I *could* write code that catches RuntimeException and
responds my doing something destructive; but whose fault would that be?)

* Class A has a method (f) that throws an exception (E) only because it
relies on another member method (g) that throws E.
* B subclasses A and overrides g such that it does not throw E, and even
erases it from the signature so it CANNOT EVER throw E.
* Calls like "new B().f()" shouldn't have to handle E because it's not
possible that it is thrown.

Now, in this particular instance (which says nothing of other scenarios)
there is no danger in quashing E by overriding f inside B.

And again, that's true only if the code never changes. 99% of software
bugs exist because some assumption was initially true, and then it
became false and no one bothered to notice that a remote piece of code
depended on that assumption.

I'm absolutely
not advocating generically quashing exceptions when they might occur.

Of course you're not. No one is advocating that. We're talking about
exceptions that are impossible to actually throw from the code that's
been written.

That's what bugs me about you altering my original post the way you did. I
pointed this out as a possible problem and, again I say, if there is the
possibility that Sub can ever throw MyException, you cannot quash it.

Perhaps I misunderstood. Did you really mean to imply that I should
declare a checked exception if it might be possible that anyone will
*ever* modify the code in the future in a way that throws that
exception? Even if such a modification were a mistake, and the
exception shouldn't be thrown at all?

Unless you wish to add "throws Throwable" to the end of every method
declaration in your code, you must draw a line somewhere. I've yet to
see where that line is drawn in your view, but it has to be there.
Where ever you draw that line (short of "throws Throwable"), it's going
to be possible that someone (maybe entirely by accident) adds code that
might throw that exception. If that happens, then you're again faced
with this choice: do you want to continue and maybe do something
horribly wrong because you wrote an empty catch block, or do you want to
report the error and abort whatever you're doing?

I add
to your argument that converting it to a RuntimeException can wreak havoc on
the unsuspecting callers just as well as quashing it.

I've yet to see how, though. You keep saying that, and haven't said a
word to support it. Again, there's a *huge* difference between throwing
an exception that merely makes the software stop working, on the one
hand, and potentially destructive behavior on the other. I think it's
clear to me that it's better to throw the RuntimeException. It's just
one short piece of code, and it means you're safe from causing billions
of dollars of damage and liability by zeroing out someone's bank
account, or forgetting to add enough fuel for the next airplane flight,
or silently doing something wrong in whatever other application domain
your software lives.

Use of a quality debugger to step through the code would help locate the
error in the same amount of time regardless of whether it's quashed or
converted, so both, IMHO, are just as bad.

I'm a bit confused here... do you typically run production code in a
debugger? By the time the debugger comes into play, how many bank
accounts have been set to zero?


I'll skip the chest beating part. Yes I'm offended. Fact is, you
waltzed in without a clue who you were conversing with, and you made
statements about my life and motives with no way to know whether they
were true or not, simply because it was to your rhetorical advantage for
other people to think they were. Nevertheless, I'll get over it.

--
www.designacourse.com
The Easiest Way to Train Anyone... Anywhere.

Chris Smith - Lead Software Developer/Technical Trainer
MindIQ Corporation

 

[Chris Smith]

And, as this was example code, I didn't clutter it with putting those kinds
of comments in. The point of the example was that I wouldn't convert it to a
runtime exception. Chris, placing comments is exactly what I'd do in
production code.

Actually, my comments to Tony were regarding something other than your
own code. I was referring to a situation where the right thing to do is
nothing. That's different from a situation where you just haven't
thought about the right thing to do, or where you don't think the choice
will ever arise.

InterruptedException is often involved in these kinds of situations,
because threads are sometimes interrupted in order to nudge them to
reconsider a predicate of a loop, or some such thing, such as when
you've just set an exit flag and now want to prompt the thread to exit.
If you put the inner part of a "while (!shouldExit)" in a try block, it
makes sense to catch InterruptedException at the end of the loop body,
and the next logical thing to do is recheck the shouldExit field and
exit if needed.

To use your example of the InterruptedExample as an answer
to Mr. Morris:

try { Thread.currentThread().sleep(1000); }
catch (InterruptedException err) { throw new RuntimeExcepton(err); }

I have, on the other hand, also done this when interruption is not
expected. Whether that's the case in the code you posted depends on
*why* you want to wait for a second.

However, Chris, I'd like to point out that this is the unfortunate effect of
your inacurrate edit of my original post. Someone else has taken my post,
out of context and slammed it for reasons that I already answered in the
stuff you cut.

No, not really. Tony responded on the merit of your post, citing
"unforeseeable" circumstances that might cause the exception to be
thrown even though you were initially convinced that it couldn't be
thrown at all. That's exactly the same problem I have with that same
piece of code. My response to Tony, though, was just meant to avoid a
flurry of "what about this..." responses to Tony's absolute statement
about ignoring exceptions, and to see about Tony's agreement on a gray
area at the border of his statement. I'm still interested in what Tony
has to say there.

--
www.designacourse.com
The Easiest Way to Train Anyone... Anywhere.

Chris Smith - Lead Software Developer/Technical Trainer
MindIQ Corporation

 

[Tony Morris]

This would probably be one of those cases that doesn't fall under ALL

circumstances. Or, Mr. Morris, do you ALWAYS do this?

Since I don't have a grasp on the complete context of this conversation, I
can only say that I ALWAYS throw a RuntimeException (or subclass of) if my
application enters an unforeseeable state - for example an
InterruptedException on a thread that "should never" be interrupted
according to requirements.

 

[Tony Morris]

No, not really. Tony responded on the merit of your post, citing

"unforeseeable" circumstances that might cause the exception to be
thrown even though you were initially convinced that it couldn't be
thrown at all. That's exactly the same problem I have with that same
piece of code. My response to Tony, though, was just meant to avoid a
flurry of "what about this..." responses to Tony's absolute statement
about ignoring exceptions, and to see about Tony's agreement on a gray
area at the border of his statement. I'm still interested in what Tony
has to say there.

I agree that there are two sides to this argument, but I still agree that an
exception should never be ignored.
An InterruptedException is more of a control flow mechanism than a typical
exception, so the "subjectiveness" becomes more apparant.
If you are expecting an InterruptedException and you are required to do
nothing in that case, it is possible to argue that you are in fact not
ignoring the exception - i.e. you have met requirements by providing a null
implementation of the "exception" [sic - poorly designed control flow
mechanism].
Log it perhaps? Provide an boolean isInterrupted() method?
I know - it's a gray [grey for us "English speakers ] area.

 

[Java Architect]

[SNIP]

And again, that's true only if the code never changes. 99% of software
bugs exist because some assumption was initially true, and then it
became false and no one bothered to notice that a remote piece of code
depended on that assumption.

Here's where Unit tests save you. If I ever made an assumption like this,
I'd have a test of the method g() that fails if it ever throws anything.

Again, I'm answering the OP's question, how to avoid dealing with the
exception in callers. Your solution did not answer that as, you proposed
having the callers wrap the call and convert a checked exception to a
runtime exception.

You want to modify my suggestion to read:

class B extends A {
void g() { ... }

void f() { try { g(); } catch (E err) { throw new
RuntimeException(err); }
}

That's fine. Just a different approach. I'd rather see a failed unit test
than have my support engineers call up asking why they're system shut down
(and, since they are ignorant of programming, have no idea what a stack
trace is or how to get at it).

You could do this same thing and add a unit test to test for
RuntimeException, but then, throwing the RuntimeException really only adds
to the amount of code, because both tests would fail with just as much
indication of the cause.

Perhaps I misunderstood. Did you really mean to imply that I should
declare a checked exception if it might be possible that anyone will
*ever* modify the code in the future in a way that throws that
exception? Even if such a modification were a mistake, and the
exception shouldn't be thrown at all?

What I was implying was that, /in this case/, there is no need to throw a
runtime exception. And, in cases where the exception could be thrown, it
shouldn't be converted to an unchecked exception.

I can't help but think you're trying to use two contradictory ideas to
arrive at the same conclusion:

* On one hand, you're saying that it's okay to convert to an unchecked
exception because /the exception doesn't occur/.
* On the other hand, you're saying that /the exception might occur/ so you
need to handle it (which you do by converting to an unchecked exception).

My argument is:

* If the exception absolutely can't occur, quash it (this is not "Not
thinking of the right thing to do") and write a unit test that will fail if
someone screws up the assumption
* If the exception can occur, declare it (or an implementation neutral,
checked, exception).

Again, the OP's post was clear. He didn't want callers to have to deal with
the prob because it wouldn't occur based on his subclassing. I happen to
agree that the code will change in the future and leave him strung out at
3AM trying to find a bug. Still, if it's what he wants to do...

I've yet to see how, though. You keep saying that, and haven't said a
word to support it.

Again, I think the difference here is that I'm not saying a runtime
exception is worse than quashing an exception. I'm saying that, if the error
can occur, and you convert to a runtime exception, that's just as bad a
design as quashing it. My point is that, if you're gonna put the code in to
convert, you obviously think the exception can occur. RuntimeException is
intended for things that are unforeseeable. In this case, the error is
foreseeable so converting it to a RuntimeException and changing the throws
clause to state that no exception can be thrown is, IMHO, a design error.

Again, there's a *huge* difference between throwing
an exception that merely makes the software stop working, on the one
hand, and potentially destructive behavior on the other. I think it's
clear to me that it's better to throw the RuntimeException. It's just
one short piece of code, and it means you're safe from causing billions
of dollars of damage and liability by zeroing out someone's bank
account, or forgetting to add enough fuel for the next airplane flight,
or silently doing something wrong in whatever other application domain
your software lives.


I'm a bit confused here... do you typically run production code in a
debugger? By the time the debugger comes into play, how many bank
accounts have been set to zero?

Since the error would have been caught by my unit test (as earlier pointed
out), the code would never have made it to production. As I've stated
elsewhere, unit tests are not panaceas. However, I've also stated that I
would have a unit test specifically for this assumption.

I'll skip the chest beating part. Yes I'm offended. Fact is, you
waltzed in without a clue who you were conversing with, and you made
statements about my life and motives with no way to know whether they
were true or not, simply because it was to your rhetorical advantage for
other people to think they were. Nevertheless, I'll get over it.

I never made any remark about your life. Don't know you, don't pretend to.
You may be one of the smartest men in the world for all I know, doesn't
change the fact that I disagree with you about this. The statement I made
wasn't for rhetorical advantage, and I don't think arguments should be won
based on rhetoric. I was pissed because you editted my argument in a manner
that DID (regardless of intent) make my argument to be something other than
it was, and as such made your argument appear stronger.

Whatever. You have your solution, I have mine. You present your solution,
I'll present mine. It's a free market for ideas.

 

[Java Architect]

Actually, my comments to Tony were regarding something other than your
own code. I was referring to a situation where the right thing to do is
nothing. That's different from a situation where you just haven't
thought about the right thing to do, or where you don't think the choice
will ever arise.

Unfortunately, that's exactly the situation we have here. Again, you tend to
resort to dubias argumentative tactics like ad hominem (what you've done
here is a subtle form of it).

We happen to disagree about what the right thing to do is. That is not the
same as not thinking about it.

[SNIP]

No, not really. Tony responded on the merit of your post

Yes, really. Tony quoted my post via your slashed version that took out my
comments and erased my logic for quashing the exception.

 

[Java Architect]

Tony,

I'm not being pedantic. This is a sincere inquiry. If the state is
unforseeable, how do you know to throw an exception at all? I always wonder
when a statement like this is made. I've heard this one before, and never
got a good answer to my follow up question.

And, Chris, this is a form of the problem that I have with your argument. I
read your solution and description to read:

1) X can't happen, so we'll do Y.
2) X might happen, so we'll do Z as well.

Problem is that statement 2 necessarily shoots down statement 1.

 

[Java Architect]

I agree that there are two sides to this argument, but I still agree that an
exception should never be ignored.

I'm in agreement with you.

An InterruptedException is more of a control flow mechanism than a typical
exception, so the "subjectiveness" becomes more apparant.
If you are expecting an InterruptedException and you are required to do
nothing in that case, it is possible to argue that you are in fact not
ignoring the exception - i.e. you have met requirements by providing a null
implementation of the "exception" [sic - poorly designed control flow
mechanism].
Log it perhaps? Provide an boolean isInterrupted() method?
I know - it's a gray [grey for us "English speakers ] area.

If Chris hadn't butchered my code, you'd have been able to see that the case
I was talking about was a case in the mode of the InterruptedException where
it's really something that doesn't affect the situation.

The context if the argument was someone having overriden a called method
that threw the exception such that it didn't even declare the checked
exception and wanting callers of a method that called the method not to have
to deal with the exception that, now couldn't be thrown.

 

[Java Architect]

[SNIP]

I'll skip the chest beating part.

What do you call /I've been posting here for 7 years! You've been posting
for 5 days./ Dude, you challenged my credibility based on some hyperbole,
and I was responding with my credentials. Sorry if that offended

Yes I'm offended. Fact is, you waltzed in without a clue who you were

conversing with

I don't care WHO I'm conversing with. Everyone, myself included, makes
mistakes, and NO ONE has the one perfect solution. So, get a grip. If some
guy comes here, without nary a post to his name and shows us both why we're
wanking, then I'd say, thanks for the knowledge upgrade, I would not get
offended.

and you made statements about my life and motives with no way to know whether they
were true or not, simply because it was to your rhetorical advantage for
other people to think they were.

Never made any statements about your life, and don't see how the motive
could be a rhetorical advantage even if I was seeking one. IF I was going to
try that kind of argument, I'd talk about things like how long someone's
been posting, how I'm friends with Roedy, David, etc... But, I don't do
those things. I simply make an argument based on the code.

 

[Tony Morris]

1) X can't happen, so we'll do Y.

X can't happen but we are forced to handle the case in order to satisfy the
compiler.
If for some unforeseeable reason, the compiler is "right", do Y.

I can think of many examples where this applies.
The fact that InterruptedException is more of a control flow mechanism than
a typical "exceptional case" is only obscuring the matter (at least for me
anyway).

 

[Chris Smith]

Here's where Unit tests save you. If I ever made an assumption like this,
I'd have a test of the method g() that fails if it ever throws anything.

Yes, the unit tests are a good thing to have. No, they don't excuse you
from good coding practices. They are not particularly relevant to our
discussion of whether this is a good coding practice. This simply isn't
a situation where 100% code coverage from unit tests (as rare as that
is) is going to help much.

You want to modify my suggestion to read:

class B extends A {
void g() { ... }

void f() { try { g(); } catch (E err) { throw new
RuntimeException(err); }
}

Yes, that's exactly what I want to do. No, it's not just a preference
or stylistic thing.

I can't help but think you're trying to use two contradictory ideas to
arrive at the same conclusion:

* On one hand, you're saying that it's okay to convert to an unchecked
exception because /the exception doesn't occur/.
* On the other hand, you're saying that /the exception might occur/ so you
need to handle it (which you do by converting to an unchecked exception).

That would be black and white version of the argument, yes. More
specifically, I'm saying that it would represent a bug in the
application for the exception to occur, but that bugs in applications
are possible.

You don't write intricate exception handling code for potential bugs in
code. There just isn't time for it. Instead, you find easy ways to get
the code to fail quickly: unchecked exceptions, assertions, etc. But
you *do* want the code to fail if there's a bug that results in an
unexpected exceptional condition.

My argument is:

* If the exception absolutely can't occur, quash it (this is not "Not
thinking of the right thing to do") and write a unit test that will fail if
someone screws up the assumption
* If the exception can occur, declare it (or an implementation neutral,
checked, exception).

Again, that's the black and white version. What about the case where it
would represent an application bug for the exception to occur? You
write...

I happen to
agree that the code will change in the future and leave him strung out at
3AM trying to find a bug. Still, if it's what he wants to do...

So presumably you think that checked exceptions that should never occur
ought to be given the same care as those that should. Why? What makes
these bugs special, as compared to NullPointerException, or
ArrayIndexOutOfBoundsException? These things, too, are just as likely
(perhaps more likely) to occur as the result of an application bug.
Should you catch them and wrap them in a checked exception to ensure
that they are handled?

Your "it can or it can't" logic isn't capturing the need to protect
against application bugs, which are too numerous to merit individual
handling, and yet still need to cause the application to abort its
operation and stop before it does some damage.

If you disagree with using unchecked exceptions for this purpose, then I
wonder how you can stand working in Java as a programming language, or
for that matter working in any environments that use assertions for
reliability control, or deploying on operating systems that reserve the
first page of address space as a guard page so that they can catch
dereferencing of null pointers in non-Java languages that don't check
this as a matter of course. (FYI, practically all modern operating
systems do this last bit.) All of those simple precautions are in
direct conflict with your "it will or it won't" approach to handling
potential bugs.

Since the error would have been caught by my unit test (as earlier pointed
out), the code would never have made it to production. As I've stated
elsewhere, unit tests are not panaceas. However, I've also stated that I
would have a unit test specifically for this assumption.

Fine, so I forgot to mention that your unit test fails to catch this
case. The question remains: which do you prefer?

Whatever. You have your solution, I have mine. You present your solution,
I'll present mine. It's a free market for ideas.

I'm not worried about what you do. Your decision is yours, and your
liability for broken code is yours. I'm worried about people who read
your newsgroup post and adopt the code as a model for their own without
thinking about the damage it could cause.

--
www.designacourse.com
The Easiest Way to Train Anyone... Anywhere.

Chris Smith - Lead Software Developer/Technical Trainer
MindIQ Corporation

 

[Roedy Green]

What do you call /I've been posting here for 7 years! You've been posting
for 5 days./ Dude, you challenged my credibility based on some hyperbole,
and I was responding with my credentials. Sorry if that offended

I think what may be going on has nothing to do with the supposed
debate. What we may have is a dominance challenge, trying to make one
of the regulars look foolish. It is standard male gorilla behaviour,
complete with feces flinging.

Symptoms are when people start telling each other what they intended
to say, or twist words to interpret in the silliest possible way.

When one of these battles gets going, the participants are attempting
to put down rather than persuade.

Perhaps someday we will have AI filters to screen that nonsense.
Perhaps someday we will have subnewsgroups where people agree to
refrain from ad hominems. Perhaps there will be some sort of forum
where it is impossible to make personal comments, starting with purely
anonymous posts.

I get sick to the stomach. I find these battles drain my energy which
is already quite limited. There are so many things that need to get
done, and yet we humans put these petty squabbles as top priority.

Perhaps resisting the temptation to defend oneself might work.

 

[Roedy Green]

If Chris hadn't butchered my code

You posted your code. Nobody touched it. Anyone who wants to look at
it can view it exactly as you typed it. No one is under any
obligation to quote it at all, much less in entirety. You are free to
quote yourself if there is some issue you want to bring up.

Chris did not butcher your code; he refused to clean it up for you.

 

[Chris Smith]

What do you call /I've been posting here for 7 years! You've been posting
for 5 days./

It's a very incredulous response to your comment to the effect of "I
understand that you try to make a name for yourself here and generate
some consulting fees". Your implication that I just popped in for some
quick self-advertising by picking a fight with you is insulting, and
just so inconsistent with facts that I still can't believe you said it.
I told you exactly how long we've both been here so that you'd realize
how ludicrous it is to claim I'm only posting here to take advantage of
you.

Frankly, and this is the point, I don't care about what you do in your
code, but I'm in this newsgroup to help people learn Java. The instant
you start giving bad advice, I'm going to object to it. When you start
being rude to me because I object, I'm going to be a bit miffed by the
whole thing. That's how the world works. If you're rude to people,
they get upset at you.


By the way, the convention on USENET is to quote enough of someone's
post to give some context for your reply, *not* to repeat the whole
thing. Someone who wanted to know what you wrote would be welcome to
read your post. It's almost certainly still on anyone's news server,
and probably archived at Google by now. I sure didn't cancel any of
your posts; even if I tried, very few news servers honor cancels any
more and I wouldn't get very far. People (at least courteous people)
are going to shorten your posts before responding to them, and if your
posts have content, that means that they are going to cut out
potentially valuable things that you've said. It's really not meant as
an affront against you; it's meant as consideration for others who are
reading the newsgroup.

--
www.designacourse.com
The Easiest Way to Train Anyone... Anywhere.

Chris Smith - Lead Software Developer/Technical Trainer
MindIQ Corporation

 

[Chris Smith]

I can think of many examples where this applies.
The fact that InterruptedException is more of a control flow mechanism than
a typical "exceptional case" is only obscuring the matter (at least for me
anyway).

Just a side comment. It's true that InterruptedException is less likely
to be exceptional than IOException, for example. Nevertheless, it's
sort of a fundamental problem with common use of exception handling that
the person writing the code isn't really who ought to be responsible for
deciding what's an "exceptional case". Hence, I find it more helpful to
conceive of checked exceptions, at least, in terms of whether the method
completed normally than whether the situation is really "exceptional".

For example, maybe I've got a spreadsheet application that checks an
internet site for updates to its data files or code on startup (not so
far out, really). What if the system isn't connected to the internet
when the application is started? At some point, there's going to be an
IOException thrown. This isn't really an exceptional case. In fact,
it's probably not even worth logging the exception. For some systems,
in fact, this code may NEVER succeed, because the computer just doesn't
contain a modem or network card. Nevertheless, the right thing to do is
just skip the rest of the update and then continue with no special
actions. The attempt to establish a network connection didn't
successfully complete, though, so there's an exception in use.

So I don't think this case is really limited to InterruptedException at
all. It's just about an exception not necessarily being an error
condition. There are some exceptions that are more or less likely to be
real error conditions (and unchecked exceptions should always be real
error conditions), but there are still reasons for catch blocks that
contain no statements -- but possibly still contain comments explaining
the purpose.

--
www.designacourse.com
The Easiest Way to Train Anyone... Anywhere.

Chris Smith - Lead Software Developer/Technical Trainer
MindIQ Corporation