Re: Overriden method doesn't throw Exception, super may.

From: Java Architect (danc_at_dynamicresolve.com)
Date: 07/13/04 

Date: Mon, 12 Jul 2004 17:35:56 -0700

"Chris Smith" <cdsmith@twu.net> wrote in message
news:MPG.1b5ccfae5d43666a98970b@news.altopia.net...
[SNIP]

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

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.

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

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

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.

Relevant Pages

  • Re: Overriden method doesnt throw Exception, super may.
    ... just as bad as ignoring the exception. ... Throwing a RuntimeException will only stop code from working. ... > not advocating generically quashing exceptions when they might occur. ... > to your argument that converting it to a RuntimeException can wreak havoc on ...
    (comp.lang.java.programmer)
  • Re: .Net Exceptions
    ... exception hierarchy of fatal vs. non-fatal exceptions that would always be ... It doesn't matter - a unit test only tests your code, ... not the actual implementation of the external component. ...
    (microsoft.public.dotnet.general)
  • Re: Try - catch in an Unit test
    ... my software fires an exception. ... I am writing an unit test in which I start a timer and I send the ... Is there any way to actually get to actually execute the catch ...
    (microsoft.public.vstudio.general)
  • Re: .Net Exceptions
    ... >> that's what Exception and Error in Java represent. ... > recover from an exception or it doesn't. ... things if the newly thrown exception type is not explicitly meant to be ... > if it did then you are really writing a unit test that validates the ...
    (microsoft.public.dotnet.general)
  • Re: Unit Testing Non-Believer
    ... I did not test with database code. ... When I write my unit test, I create tests that I expect to pass, before ... totally wrong, I do expect exception. ... that customer. ...
    (borland.public.delphi.non-technical)