}
}
Campbell Ritchie wrote:Try that. See what happens. See whether it would be any better if you change line 1 to String[] words = new String[3]; Now try the original version I showed you (minus lines 2‑5). Try as you will, you cannot get those Exceptions out of it. That array initialiser has four Strings in, and will always produce a 4‑element array. No risk of any errors like that. If you specify the length of the array yourself, there is a risk of not filling the array completely (so you have a null), or of trying to fit n elements into n − 1 spaces, when you get an out of bounds Exception. If you use an array initialiser and use the correct formats of loops, you will not get Exceptions out of arrays. You will never try to fill a 5‑length array with 4 elements, nor try to fill a 3‑length array with 4 elements.
}
Ivan Addeo wrote:Copied the code in Notepad++, added main method but won't compile. There is an illegal start of expression, and missing ';'
Liutauras Vilda wrote:
Ivan Addeo wrote:Copied the code in Notepad++, added main method but won't compile. There is an illegal start of expression, and missing ';'
Add comma at the end of line 8.
}
That just goes to show how difficult it can be for a compiler to find the correct error message. And sorry for the mistake.Ivan Addeo wrote:. . . Did it, but i've errors about line 9: not a statement, and ';' expected.
Campbell Ritchie wrote:
That just goes to show how difficult it can be for a compiler to find the correct error message. And sorry for the mistake.Ivan Addeo wrote:. . . Did it, but i've errors about line 9: not a statement, and ';' expected.
}
Liutauras Vilda wrote:just missing comma at the end of line 8.
Liutauras Vilda wrote:
Liutauras Vilda wrote:just missing comma at the end of line 8.
, - comma
; - semicolon
}
Liutauras Vilda wrote:Don't know what to quote of your (Ivan Addeo) last post.
What Campbell basically told, is next..
Instead of creating an array and separately initializing elements, i.e.:
Better is initialize that way (if elements are known at the beginning):
In this way you're not risking to leave some uninitialized elements, which would result in null pointers in this case. As you noticed, in first example last element which is at index position 3, 's[3]' left uninitialized, and trying to do some work with it could cause you a null pointer exception.
}
Ivan Addeo wrote:He says that i'll avoid null, and then he says that this code will propt nulls. This is the part i'm not understanding :P
L Hasan wrote:It sounds like he's trying to say, there would be situations where you declare and instantiate an array object, with a size, possibly without declaring all of it's elements. Whether this comes down to forgetting to init one, or all of the elements, or some later error in the code that prevents all elements in the array being initialised.
This might be fine for arrays of primitives where values are default initialised to 0, or false, but with Objects, trying to access a reference to a 'null' value could cause undesired effects.
If you use an array initialiser in a declaration, you will never have the problem of a null element. If you initialise using during assignment, these undesired effects may happen.
Hope that makes some sense,
L.
}
L Hasan wrote:Hey,
I'll break this down. Let's say you declare and instantiate an array object (with a preset size), and later assign the elements; you could end up in a situation like:
[Un]Luckily, in this case, the println() method will not complain, it will simply print "This" "is" "a" "null". In other applications though, this could be a serious flaw that won't be found until runtime.
This is why Campbell says it is better to use the array initialiser during the declaration phase:
String[] myStrings = {"This", "is", "a", "test"};
As we will always have an array, that is the appropriate fixed size (of 4 elements), to contain the number of elements we pass in. No chance for undesired effects.
Hope that helps,
L.
}
}
There is no possibility to edit my post?
All things are lawful, but not all things are profitable.
Never use == true , or == false.. . . if(canInit == true) . . .
Campbell Ritchie wrote:What a nice post You explained what I meant better than I could have.
Except you wroteNever use == true , or == false.. . . if(canInit == true) . . .
I have written about that many times. It is very error‑prone.
Use
if (b) ...
or
if (!b) ...
instead.
Your best guess is correctL Hasan wrote:My best guess is that you could mistakenly assign
That is exactly what happens; we see it every now and again on this forum. Because Java® has got rid of the notion that 0 ≡ false and non‑0 ≡ true, there is no need for the C convention of writingL Hasan wrote:. . . Could you tell me why it is error prone? My best guess is that you could mistakenly assign:
. . . .
Campbell Ritchie wrote:An assignment instead of == will produce a compiler error unless the left operand of the = is a boolean variable (or possibly a Boolean; I haven't checked for a very long time).
I have checked more recently. The following crappy code compiles and sets b2 to true:-A few minutes ago, I wrote:. . . I haven't checked for a very long time. . . .