Velocity Reviews - Computer Hardware Reviews

Velocity Reviews > Newsgroups > Programming > Java > [jdk1.5.0_01] assert false

Reply
Thread Tools

[jdk1.5.0_01] assert false

 
 
Paul Chapman
Guest
Posts: n/a
 
      02-04-2005
I've just updraded to jdk1.5.0_01. I've already found that generics improve
my code.

I've just been rewriting some base-class methods which should never be
called. Previously they might look like:

protected int method()
{
throw new RuntimException();
}

The compiler doesn't complain that there's no return statement, presumably
because it knows that the throw means the method will never return normally.

I am rewriting these to use assert, thus:

protected int method()
{
assert false;
}

This seems to me to be a reasonable thing to do, and an improvement. The
new compiler complains that there is no return statement. I think it might
be improved to recognize that the assertion will always throw an exception.

Any views?

Cheers, Paul


 
Reply With Quote
 
 
 
 
Andy Hill
Guest
Posts: n/a
 
      02-04-2005
"Paul Chapman" <(E-Mail Removed)-online.co.uk> wrote:

>I've just updraded to jdk1.5.0_01. I've already found that generics improve
>my code.
>
>I've just been rewriting some base-class methods which should never be
>called. Previously they might look like:
>
>protected int method()
>{
> throw new RuntimException();
>}
>
>The compiler doesn't complain that there's no return statement, presumably
>because it knows that the throw means the method will never return normally.
>
>I am rewriting these to use assert, thus:
>
>protected int method()
>{
> assert false;
>}
>
>This seems to me to be a reasonable thing to do, and an improvement. The
>new compiler complains that there is no return statement. I think it might
>be improved to recognize that the assertion will always throw an exception.
>
>Any views?
>
>Cheers, Paul
>

Assertions can be turned off or on (unlike an exception throw). So what
happens in your code when the assert is turned off? Compiler error make sense,
now?

 
Reply With Quote
 
 
 
 
Jim
Guest
Posts: n/a
 
      02-04-2005
On Fri, 4 Feb 2005 20:36:53 -0000, "Paul Chapman"
<(E-Mail Removed)-online.co.uk> wrote:

>I've just updraded to jdk1.5.0_01. I've already found that generics improve
>my code.
>
>I've just been rewriting some base-class methods which should never be
>called. Previously they might look like:
>
>protected int method()
>{
> throw new RuntimException();
>}
>
>The compiler doesn't complain that there's no return statement, presumably
>because it knows that the throw means the method will never return normally.
>
>I am rewriting these to use assert, thus:
>
>protected int method()
>{
> assert false;
>}
>
>This seems to me to be a reasonable thing to do, and an improvement. The
>new compiler complains that there is no return statement. I think it might
>be improved to recognize that the assertion will always throw an exception.
>
>Any views?
>
>Cheers, Paul
>

Try

public class UnsupportedOperationException extends RuntimeException

"Thrown to indicate that the requested operation is not supported."


Jim

 
Reply With Quote
 
dolapo@gmail.com
Guest
Posts: n/a
 
      02-05-2005
Jim wrote:
> Try
>
> public class UnsupportedOperationException extends RuntimeException
>
> "Thrown to indicate that the requested operation is not supported."
>
>
> Jim

This is a good suggestion. Any reason the methods aren't abstract ?

 
Reply With Quote
 
Paul Chapman
Guest
Posts: n/a
 
      02-06-2005
Andy,

> Assertions can be turned off or on (unlike an exception throw). So

what
> happens in your code when the assert is turned off? Compiler error make

sense,
> now?


Hmm, yes.

I guess I might put the throws back in. They should never be executed, so
there's no performance penalty.

Cheers, Paul


 
Reply With Quote
 
Paul Chapman
Guest
Posts: n/a
 
      02-06-2005
I wrote:

> I've just been rewriting some base-class methods which should never be
> called. ...


This made me think.

abstract class ClassA {
public void method() {assert false;} }

class ClassB extends ClassA {
public void method() {doSomething();} }

....

ClassA thing = ...

...

thing.method(); // only ever called if thing isKindOf ClassB

Is this the best way in which to write this? Or is it better to leave the
definition of method() out of ClassA, and rewrite the last statement above:

((ClassB) thing).method();

If the program logic is wrong, in the former case the assertion will fail at
runtime, while in the latter case the cast will fail at runtime.

The latter method uses a cast, while the former method (necessarily) defines
a method which will never be called. Which is the lesser evil? Or is there
a better way still?

In Smalltalk (where there is no casting), the convention is to write:

ClassA>>method
^self subclassResponsibility

where:

Object>>subclassResponsibility
^self error: 'My subclass should have implemented this method'

Cheers, Paul


 
Reply With Quote
 
Paul Chapman
Guest
Posts: n/a
 
      02-06-2005
(My ISP is having trouble forwarding posts. Sorry for any delay.)

> Any reason the methods aren't abstract ?


Only one subclass is ever asked to run the method. If the base-class method
was abstract, all the other subclasses would just have the same problem, and
have to throw an exception to indicate a logic error in the program.

Cheers, Paul


 
Reply With Quote
 
Stefan Schulz
Guest
Posts: n/a
 
      02-06-2005
On Sun, 06 Feb 2005 00:19:00 +0000, Paul Chapman wrote:

> (My ISP is having trouble forwarding posts. Sorry for any delay.)
>
>> Any reason the methods aren't abstract ?

>
> Only one subclass is ever asked to run the method. If the base-class method
> was abstract, all the other subclasses would just have the same problem, and
> have to throw an exception to indicate a logic error in the program.


So, the base class, and all it's subclasses except for one have nothing to
do with the method? In that case, why include it in the base class at all?
It belongs into the subclass alone.

--
In pioneer days they used oxen for heavy pulling, and when one ox
couldn't budge a log, they didn't try to grow a larger ox. We shouldn't
be trying for bigger computers, but for more systems of computers.
--- Rear Admiral Grace Murray Hopper

 
Reply With Quote
 
Paul Chapman
Guest
Posts: n/a
 
      02-06-2005
> So, the base class, and all it's subclasses except for one have nothing to
> do with the method? In that case, why include it in the base class at all?
> It belongs into the subclass alone.


Because it is called on a variable declared as a reference to the base
class, wich means the base clkass has to declare or define it.

Can you suggest a better solution?

Cheers, Paul


 
Reply With Quote
 
Chris Smith
Guest
Posts: n/a
 
      02-06-2005
Paul Chapman <(E-Mail Removed)-online.co.uk> wrote:
> > So, the base class, and all it's subclasses except for one have nothing to
> > do with the method? In that case, why include it in the base class at all?
> > It belongs into the subclass alone.

>
> Because it is called on a variable declared as a reference to the base
> class, wich means the base clkass has to declare or define it.
>
> Can you suggest a better solution?


We haven't seen (and don't want to see) enough code and requirements to
decide... but it sounds very much like you might have some code that's
out of place. If there's a method that's only declared in one subclass,
then you shouldn't generally be calling it with a base class reference.
Either you have thrown away information somewhere that you shouldn't
have thrown away, or there is yet more code that *also* ought to be
moved from its current location into the subclass.

If circumstances have forced you to lose that information (i.e., to have
a base class reference instead of a subclass reference), then you should
cast it back again as soon as you re-learn this additional type
information about the reference.

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

Chris Smith - Lead Software Developer/Technical Trainer
MindIQ Corporation
 
Reply With Quote
 
 
 
Reply

Thread Tools

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is On
HTML code is Off
Trackbacks are On
Pingbacks are On
Refbacks are Off


Similar Threads
Thread Thread Starter Forum Replies Last Post
To assert or not to assert... ImpalerCore C Programming 79 05-17-2010 12:47 PM
False positive, false intrusion, false alarm Nick Computer Security 3 04-26-2006 07:40 PM
assert 0, "foo" vs. assert(0, "foo") Thomas Guettler Python 3 02-23-2005 07:53 PM
assert(x) and '#define ASSERT(x) assert(x)' Alex Vinokur C Programming 5 11-25-2004 08:48 PM
RE: remove assert statement (Was: Re: PEP new assert idiom) Robert Brewer Python 1 11-07-2004 06:53 PM



Advertisments