int vs boolean

[Saral Saxena]

here is I have a variable transcation to which I can apply the condition OF BOOLEAN TYPE



public void setDisplayHardBlockScreen(boolean val, ITransaction transaction)
throws PosException {
if (transaction != null) {

but if I have of int type card number and I want to achieve this same condition then how it is possible..

if (cardNumber != null) {

[Matthew Brown]

If it's an int, it will never have a null value. So you'd need to have a value that signified the equivalent. 0 might be OK in some circumstances, not in others.

Or you could use an Integer instead, which can have a null value.

[Campbell Ritchie]

There is something wrong with the design if you are using null as some sort of default value. Obviously checking that a null has not been passed is good practice. You should find here that letting nulls into your code is the No 1 Java™ mistake. Although there are at least two serious mistakes in that website.

[James Boswell]

I'm sorry, I don't understand what is being asked here.

[Carlo Moore]

I don't think it's a good idea to be using int for the card numbers. There are a few reasons why.

[Jeff Verdegan]

Carlo Moore wrote:I don't think it's a good idea to be using int for the card numbers. There are a few reasons why.

It's impossible to say without knowing more about the context, her requirements and design, and what exactly this "card number" represents.

[Carlo Moore]

Jeff Verdegan wrote:
It's impossible to say without knowing more about the context, her requirements and design, and what exactly this "card number" represents.

You're right, I was thinking that in general a card number often represents something that is not of type int. Without knowing more detail it is impossible to know for sure though.

[Winston Gutkowski]

Saral Saxena wrote:but if I have of int type card number and I want to achieve this same condition then how it is possible.
if (cardNumber != null) {

Personally, I would could come up with a name for this condition and put it in a method, maybe something like

public final boolean isACard(int cardNumber) {
   return cardNumber >= 0;
}

and then use that in your code, viz:
if (isACard(cardNumber)) ...

That way, you can change the check later on if the requirements change.

It might even be worth putting it into a Card class.

"All problems in computer science can be solved by a layer of indirection" - David Wheeler.

Winston

[J. Kevin Robbins]

Campbell Ritchie wrote:Although there are at least two serious mistakes in that website.

Ok, I give up. I've read it and can't spot the mistakes except that it fails to mention the @Override annotation, but it probably pre-dates that feature. Please enlighten me.

[Jeff Verdegan]

Campbell Ritchie wrote:You should find here that letting nulls into your code is the No 1 Java™ mistake. Although there are at least two serious mistakes in that website.

I found errors in #6 and #5. One a factual error and the other just plain bad advice.

[Jeff Verdegan]

Jk Robbins wrote:

Campbell Ritchie wrote:Although there are at least two serious mistakes in that website.

Ok, I give up. I've read it and can't spot the mistakes except that it fails to mention the @Override annotation, but it probably pre-dates that feature. Please enlighten me.

1) It says that Java passes objects by reference. That is false. It passes references by value, which has some surface similarities but is really a completely different thing.

2) It advises a) Catching Exception, and b) Just printing out the exception, rather than printing the stack trace, or, more correctly, either actually handling the exception or else letting it bubble up to higher layers.

Not sure if those are what Campbell was talking about, but those are the two I found on a quick skim.

[J. Kevin Robbins]

Jeff Verdegan wrote:

1) It says that Java passes objects by reference. That is false. It passes references by value, which has some surface similarities but is really a completely different thing.

2) It advises a) Catching Exception, and b) Just printing out the exception, rather than printing the stack trace, or, more correctly, either actually handling the exception or else letting it bubble up to higher layers.

Not sure if those are what Campbell was talking about, but those are the two I found on a quick skim.

I should have spotted number 2. The first one is a bit puzzling, but I found this article which, if correct, seems to provide a good explanation.

[Jeff Verdegan]

Jk Robbins wrote:

Jeff Verdegan wrote:

1) It says that Java passes objects by reference. That is false. It passes references by value, which has some surface similarities but is really a completely different thing.

2) It advises a) Catching Exception, and b) Just printing out the exception, rather than printing the stack trace, or, more correctly, either actually handling the exception or else letting it bubble up to higher layers.

Not sure if those are what Campbell was talking about, but those are the two I found on a quick skim.

I should have spotted number 2. The first one is a bit puzzling, but I found this article which, if correct, seems to provide a good explanation.

Yeah, that's one of about half a dozen I used to link to several years ago when this would come up. Somewhere along the way I lost my file of stock answers and never rebuilt it. I haven't seen the question pop up as often as it used to.

[Campbell Ritchie]

We now have three errors suspected. They are all real errors; @Override was introduced in September 2004 and that article was written in June 2006. He ought to have know about @Override. That was the first I noticed, the second being about pass-by-reference.