«

Hello,
I have a simple (?) question.

If I write:
<code>
MyClass object = new MyClass(someArgument);
object.doStuff();
</code>

Do I have a guarantee that object is not null when I call doStuff? Or
is there a possible execution path which reaches .doStuf() with object
being null?

Thanks Phil

Philipp wrote:
> Hello,
> I have a simple (?) question.
>
> If I write:
> <code>
> MyClass object = new MyClass(someArgument);
> object.doStuff();
> </code>
>
> Do I have a guarantee that object is not null when I call doStuff? Or
> is there a possible execution path which reaches .doStuf() with object
> being null?
>
> Thanks Phil
No such guarantee.
try {
MyClass object =
new MyClass(someArgument);
object.doStuff();
} catch (someE e) {
some handling
} // guaranteed object.doStuff() won't be called if
// new MyClass(someArgument) throws.
See the JLS subsection:
15.9.4 Run-time Evaluation of Class Instance Creation Expressions
<http://java.sun.com/docs/books/jls/third_edition/html/expressions.html#15.9.4>

Philipp wrote:
> Hello,
> I have a simple (?) question.
>
> If I write:
> <code>
> MyClass object = new MyClass(someArgument);
> object.doStuff();
> </code>
>
> Do I have a guarantee that object is not null when I call doStuff? Or
> is there a possible execution path which reaches .doStuf() with object
> being null?

You do have a guarantee, unless you go out of your way to remove it,
for example with a badly designed try-catch:

<*bad* code>
MyClass object = null;
try {
object = new MyClass(someArgument);
} catch (Exception e){
System.err.println("MyClass constructor failure "+e.getMessage());
}
object.doStuff();
</*bad* code>

In this version, if the constructor throws an exception, object will be
null at the object.doStuff() call.

Patricia

bugbear wrote:
> Bo Vance wrote:
>> Philipp wrote:
>>> Hello,
>>> I have a simple (?) question.
>>>
>>> If I write:
>>> <code>
>>> MyClass object = new MyClass(someArgument);
>>> object.doStuff();
>>> </code>
>>>
>>> Do I have a guarantee that object is not null when I call doStuff? Or
>>> is there a possible execution path which reaches .doStuf() with object
>>> being null?
>>>
>>> Thanks Phil
>> No such guarantee.
>> try {
>> MyClass object =
>> new MyClass(someArgument);
>> object.doStuff();
>> } catch (someE e) {
>> some handling
>> } // guaranteed object.doStuff() won't be called if
>> // new MyClass(someArgument) throws.
>> See the JLS subsection:
>> 15.9.4 Run-time Evaluation of Class Instance Creation Expressions
>> <http://java.sun.com/docs/books/jls/third_edition/html/expressions.html#15.9.4>
>
>
> The recent thread "To check or not to check for NULL?" disagrees with you.
>

Yes, up to the point at which Patricia demonstrates a counter example.
Granted Phil's snippet didn't include a try/catch block.
For the record: I stand corrected. 'new' will never evaluate to null.
Thanks, and my apologies to Phil.
--
BV

Lew wrote:
> Philipp wrote:
>>> If I write:
>>> <code>
>>> MyClass object = new MyClass(someArgument);
>>> object.doStuff();
>>> </code>
>>>
>>> Do I have a guarantee that object is not null when I call doStuff?
>
> Yes.
>
> 'new' cannot return 'null'.
>
>>> Or is there a possible execution path which reaches .doStuf() [sic]
>>> with object
>>> being null?
>
> Bo Vance wrote:
>> No such guarantee.
>> try {
>> MyClass object =
>> new MyClass(someArgument);
>> object.doStuff();
>> } catch (someE e) {
>> some handling
>> } // guaranteed object.doStuff() won't be called if
>> // new MyClass(someArgument) throws.
>> See the JLS subsection:
>> 15.9.4 Run-time Evaluation of Class Instance Creation Expressions
>> <http://java.sun.com/docs/books/jls/third_edition/html/expressions.html#15.9.4>
>
>
> This doesn't answer the OP's question. That's how the execution might
> *not* reach 'doStuff()', but they asked how it might *reach* 'doStuff()'
> with 'object' not assigned (or assigned 'null').
>
> For that read the JLS on "definite assignment". It gets an entire chapter.
> <http://java.sun.com/docs/books/jls/third_edition/html/defAssign.html>
>
> There are ways to reach a reference without it being assigned, basically
> involving failure to deal with exceptions.
>
> Foo foo; // I hate including 'Class' or 'object' in identifiers
> try
> {
> foo = new Foo();
> }
> catch ( Exception exc )
> {
> // completely fail to handle exc
> }
> foo.doStuff(); // error
>

Thank you. Hopefully my error has elicited responses that will have
made the subject clear for the op, Phil.

--
BV

bugbear wrote:
> Patricia Shanahan wrote:
>> You do have a guarantee, unless you go out of your way to remove it,
>> for example with a badly designed try-catch:
>>
>> <*bad* code>
>> MyClass object = null;
>> try {
>> object = new MyClass(someArgument);
>> } catch (Exception e){
>> System.err.println("MyClass constructor failure "+e.getMessage());
>> }
>> object.doStuff();
>> </*bad* code>
>>
>> In this version, if the constructor throws an exception, object will be
>> null at the object.doStuff() call.
>
> I will point out that the null value of "object"
> did NOT come from new.
>
> I'm *sure* Patricia knows this.
>
> BugBear

Indeed. More specifically, the JLS guarantees that the result of the
"new MyClass(someArgument)" is a pointer to a MyClass instance, not
null. If the variable is null, it must come from somewhere else, such as
a left over value from before a try-catch block.

Initializing a final variable is the best guarantee:

final MyClass object = new MyClass(someArgument);

Any code using object must be inside any try block containing the
declaration, so it will not be executed if the constructor throws a
caught exception or error. Using "final" prevents any subsequent null
assignment to object.

Patricia

Patricia Shanahan <> wrote:
> final MyClass object = new MyClass(someArgument);
> Any code using object must be inside any try block containing the
> declaration, so it will not be executed if the constructor throws a
> caught exception or error. Using "final" prevents any subsequent null
> assignment to object.

If I had code like this:
Foo foo;
try { foo = new Foo(...); }
catch (...) { ... }
finally { ... }
foo.bar();

Then wouldn't/shouldn't the compiler reject it anyway with
words like "use of possibly uninitialized variable" ?

But then it might mislead some to just add "=null" to the
declaration, rather than correct the logic in a case like this.

Philipp wrote:
> Hello,
> I have a simple (?) question.
>
> If I write:
> <code>
> MyClass object = new MyClass(someArgument);
> object.doStuff();
> </code>
>
> Do I have a guarantee that object is not null when I call doStuff?

Yes.

>Or
> is there a possible execution path which reaches .doStuf() with
> object
> being null?

No.

Andreas Leitgeb wrote:
> Patricia Shanahan <> wrote:
>> final MyClass object = new MyClass(someArgument);
>> Any code using object must be inside any try block containing the
>> declaration, so it will not be executed if the constructor throws a
>> caught exception or error. Using "final" prevents any subsequent
>> null
>> assignment to object.
>
> If I had code like this:
> Foo foo;
> try { foo = new Foo(...); }
> catch (...) { ... }
> finally { ... }
> foo.bar();
>
> Then wouldn't/shouldn't the compiler reject it anyway with
> words like "use of possibly uninitialized variable" ?

Certainly, assuming (as I'm sure you meant) that neither the catch
block nor the finally block assigns to foo.

On Wed, 24 Sep 2008 01:48:09 -0700 (PDT), Philipp <>
wrote, quoted or indirectly quoted someone who said :

>Do I have a guarantee that object is not null when I call doStuff? Or
>is there a possible execution path which reaches .doStuf() with object
>being null?

It is quite nice. Not only can be you be absolutely sure new returned
an actual object, you can also be sure the constructor completed
normally right after the new.

Otherwise you would have an exception which you may optionally catch.
Of course you can be perverse and try to access the object in your
catch or after you have been notified of the problem.

--
Roedy Green Canadian Mind Products
http://mindprod.com/politics/harper.html
Anyone but Harper for Prime Minister of Canada