Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > comp.lang.java.programmer > #36813 > unrolled thread

null checks

Back to article view | Back to comp.lang.java.programmer

Contents

  null checks Eric Douglas <e.d.programmer@gmail.com> - 2017-07-07 08:03 -0700
    Re: null checks Arne Vajhøj <arne@vajhoej.dk> - 2017-07-07 11:49 -0400
      Re: null checks Eric Douglas <e.d.programmer@gmail.com> - 2017-07-07 08:54 -0700
        Re: null checks Arne Vajhøj <arne@vajhoej.dk> - 2017-07-07 12:12 -0400
          Re: null checks Eric Douglas <e.d.programmer@gmail.com> - 2017-07-07 10:16 -0700
          Re: null checks Joerg Meier <joergmmeier@arcor.de> - 2017-07-08 22:33 +0200
            Re: null checks Martin Gregorie <martin@address-in-sig.invalid> - 2017-07-08 21:14 +0000
              Re: null checks Eric Sosman <esosman@comcast-dot-net.invalid> - 2017-07-08 17:51 -0400
                Re: null checks Martin Gregorie <martin@address-in-sig.invalid> - 2017-07-08 22:26 +0000
              Re: null checks Arne Vajhøj <arne@vajhoej.dk> - 2017-07-08 18:28 -0400
              Re: null checks Joerg Meier <joergmmeier@arcor.de> - 2017-07-25 07:26 +0200
                Re: null checks Martin Gregorie <martin@address-in-sig.invalid> - 2017-07-25 12:12 +0000
            Re: null checks Arne Vajhøj <arne@vajhoej.dk> - 2017-07-08 18:20 -0400
              Re: null checks Eric Douglas <e.d.programmer@gmail.com> - 2017-07-10 05:35 -0700
          Re: null checks Robert Klemme <shortcutter@googlemail.com> - 2017-07-09 13:10 +0200
        Re: null checks Eric Sosman <esosman@comcast-dot-net.invalid> - 2017-07-07 12:53 -0400
          Re: null checks lewbloch@gmail.com - 2017-07-26 11:16 -0700
            Re: null checks Eric Douglas <e.d.programmer@gmail.com> - 2017-07-26 11:40 -0700
              Re: null checks Eric Sosman <esosman@comcast-dot-net.invalid> - 2017-07-26 16:40 -0400
              Re: null checks lewbloch@gmail.com - 2017-07-28 18:47 -0700
    Re: null checks Wayne <wayne@nospam.invalid> - 2017-07-07 16:24 -0400
    Re: null checks Joerg Meier <joergmmeier@arcor.de> - 2017-07-08 22:32 +0200
    Re: null checks Lothar Kimmeringer <news201705@kimmeringer.de> - 2017-07-09 15:59 +0200
      Re: null checks Arne Vajhøj <arne@vajhoej.dk> - 2017-07-11 20:30 -0400

Page 1 of 2  [1] 2  Next page →

#36813 — null checks

Correct me if I'm wrong but the NonNull is pointless?

https://help.eclipse.org/neon/index.jsp?topic=%2Forg.eclipse.jdt.doc.user%2Ftasks%2Ftask-using_null_type_annotations.htm

We should just use the null check?

https://docs.oracle.com/javase/8/docs/api/java/util/Objects.html#requireNonNull-T-

[toc] | [next] | [standalone]

#36815

On 7/7/2017 11:03 AM, Eric Douglas wrote:
> Correct me if I'm wrong but the NonNull is pointless?
> 
> https://help.eclipse.org/neon/index.jsp?topic=%2Forg.eclipse.jdt.doc.user%2Ftasks%2Ftask-using_null_type_annotations.htm
> 
> We should just use the null check?
> 
> https://docs.oracle.com/javase/8/docs/api/java/util/Objects.html#requireNonNull-T-


I am not sure that I understand the question.

Annotations can be used by compilers or check tools to
issue warnings/errors and by AOP tools to insert runtime checks
automatically.

A runtime check is just a piece of code that does a runtime check.

Two completely different purposes.

Arne

[toc] | [prev] | [next] | [standalone]

#36816

On Friday, July 7, 2017 at 11:50:05 AM UTC-4, Arne Vajhøj wrote:
> 
> I am not sure that I understand the question.
> 
> Annotations can be used by compilers or check tools to
> issue warnings/errors and by AOP tools to insert runtime checks
> automatically.
> 
> A runtime check is just a piece of code that does a runtime check.
> 
> Two completely different purposes.
> 
> Arne

So what are you trying to say, if you need a parameter to never be null use both the @NonNull and the new Objects.requireNonNull()?
Is the assert verb still necessary or useful?

[toc] | [prev] | [next] | [standalone]

#36817

On 7/7/2017 11:54 AM, Eric Douglas wrote:
> On Friday, July 7, 2017 at 11:50:05 AM UTC-4, Arne Vajhøj wrote:
>> I am not sure that I understand the question.
>>
>> Annotations can be used by compilers or check tools to
>> issue warnings/errors and by AOP tools to insert runtime checks
>> automatically.
>>
>> A runtime check is just a piece of code that does a runtime check.
>>
>> Two completely different purposes.
> 
> So what are you trying to say, if you need a parameter to never be
> null use both the @NonNull and the new Objects.requireNonNull()? Is
> the assert verb still necessary or useful?

You need to choose between approaches:
1) Annotate and let IDE/checktool give you warnings during dveelopment
2) Make a runtime check
    A) Insert the check code manually
    B) Annotate and weave the check code in via AOP

I only think it makes sense to do one.

I think approach 2A is the simple safe approach.

If you are a leading edge environment then 2B
may fit.

I don't like to rely on IDE/checktool to enforce
integrity of application.

Arne

[toc] | [prev] | [next] | [standalone]

#36819

On Friday, July 7, 2017 at 12:12:27 PM UTC-4, Arne Vajhøj wrote:
> On 7/7/2017 11:54 AM, Eric Douglas wrote:
> > On Friday, July 7, 2017 at 11:50:05 AM UTC-4, Arne Vajhøj wrote:
> >> I am not sure that I understand the question.
> >>
> >> Annotations can be used by compilers or check tools to
> >> issue warnings/errors and by AOP tools to insert runtime checks
> >> automatically.
> >>
> >> A runtime check is just a piece of code that does a runtime check.
> >>
> >> Two completely different purposes.
> > 
> > So what are you trying to say, if you need a parameter to never be
> > null use both the @NonNull and the new Objects.requireNonNull()? Is
> > the assert verb still necessary or useful?
> 
> You need to choose between approaches:
> 1) Annotate and let IDE/checktool give you warnings during dveelopment
> 2) Make a runtime check
>     A) Insert the check code manually
>     B) Annotate and weave the check code in via AOP
> 
> I only think it makes sense to do one.
> 
> I think approach 2A is the simple safe approach.
> 
> If you are a leading edge environment then 2B
> may fit.
> 
> I don't like to rely on IDE/checktool to enforce
> integrity of application.
> 
> Arne

The @NonNull doesn't appear to be required, so wasn't sure if it's necessary or helpful.
To add it in Eclipse it requires "Copy library with default null annotations to build path".
I just want to ensure a null object is never passed in to a public method.  It appears the simplest way now is the first line of the method call Objects.requireNonNull() which is the Java 8 convenience for if (passin == null) throw NPE.

[toc] | [prev] | [next] | [standalone]

#36835

On Fri, 7 Jul 2017 12:12:04 -0400, Arne Vajhøj wrote:

> I don't like to rely on IDE/checktool to enforce
> integrity of application.

Why not ? You presumably let a tool do your type checking for you all the
time. Where is the difference to null checking ?

Liebe Gruesse,
		Joerg

[toc] | [prev] | [next] | [standalone]

#36836

On Sat, 08 Jul 2017 22:33:36 +0200, Joerg Meier wrote:

> On Fri, 7 Jul 2017 12:12:04 -0400, Arne Vajhøj wrote:
> 
>> I don't like to rely on IDE/checktool to enforce integrity of
>> application.
> 
> Why not ? You presumably let a tool do your type checking for you all
> the time. Where is the difference to null checking ?
>
I'm with Arne here.

Type checking can generally be done at compile time because its static 
w.r.t code statements. 

However, the same doesn't apply to null checks. Whether a reference 
variable contains null or not depends on what has been assigned to it 
while the code was executing. Whether a null value is valid is entirely 
dependent on the logic of the code using it and so often cannot be 
checked at compile time.


-- 
martin@   | Martin Gregorie
gregorie. | Essex, UK
org       |

[toc] | [prev] | [next] | [standalone]

#36837

On 7/8/2017 5:14 PM, Martin Gregorie wrote:
> On Sat, 08 Jul 2017 22:33:36 +0200, Joerg Meier wrote:
> 
>> On Fri, 7 Jul 2017 12:12:04 -0400, Arne Vajhøj wrote:
>>
>>> I don't like to rely on IDE/checktool to enforce integrity of
>>> application.
>>
>> Why not ? You presumably let a tool do your type checking for you all
>> the time. Where is the difference to null checking ?
>>
> I'm with Arne here.
> 
> Type checking can generally be done at compile time because its static
> w.r.t code statements.
> 
> However, the same doesn't apply to null checks. Whether a reference
> variable contains null or not depends on what has been assigned to it
> while the code was executing. Whether a null value is valid is entirely
> dependent on the logic of the code using it and so often cannot be
> checked at compile time.

     ... but sometimes can be, in much the same way that Java can
usually diagnose the use of a variable that may not have had a
value assigned yet.  (By "usually" I don't mean that Java ever
fails to diagnose an actual problem, but that it sometimes raises
false alarms.)

     Perhaps we're reading the word "rely" a bit differently.  It
seems to me that if the tool can give me some help, I can "rely"
on that help.  I may not "rely entirely" on the tool, but, well,
I'll gladly accept all the help I can get ...

-- 
esosman@comcast-dot-net.invalid
Twelve hundred ninety-two days to go.

[toc] | [prev] | [next] | [standalone]

#36840

On Sat, 08 Jul 2017 17:51:45 -0400, Eric Sosman wrote:

>      ... but sometimes can be, in much the same way that Java can
> usually diagnose the use of a variable that may not have had a value
> assigned yet.  (By "usually" I don't mean that Java ever fails to
> diagnose an actual problem, but that it sometimes raises false alarms.)
>
Yes, agreed, but 'sometimes' covers a variety of sins which I didn't want 
to enumerate or qualify.

Besides, I have a fairly extensive C background and so naturally tend to 
prefer adding in runtime checks and to use null as, depending on context, 
as a completion signal or a "didn't succeed" return value. In the latter 
case I assume that those without a C background would throw an Exception 
while I'm more likely to write something like:

   Thing t = class.method();
   if (t == null)
   {
      class.getError(); 
      ...
   }
 
>      Perhaps we're reading the word "rely" a bit differently.  It
> seems to me that if the tool can give me some help, I can "rely" on that
> help.  I may not "rely entirely" on the tool, but, well, I'll gladly
> accept all the help I can get ...
>
Fair comment. In this case I tend not to 'rely' on static checks that can 
be overridden at runtime, bot of course ymmv and probably does. 


-- 
martin@   | Martin Gregorie
gregorie. | Essex, UK
org       |

[toc] | [prev] | [next] | [standalone]

#36839

On 7/8/2017 5:14 PM, Martin Gregorie wrote:
> On Sat, 08 Jul 2017 22:33:36 +0200, Joerg Meier wrote:
>> On Fri, 7 Jul 2017 12:12:04 -0400, Arne Vajhøj wrote:
>>> I don't like to rely on IDE/checktool to enforce integrity of
>>> application.
>>
>> Why not ? You presumably let a tool do your type checking for you all
>> the time. Where is the difference to null checking ?
>>
> I'm with Arne here.
> 
> Type checking can generally be done at compile time because its static
> w.r.t code statements.
> 
> However, the same doesn't apply to null checks. Whether a reference
> variable contains null or not depends on what has been assigned to it
> while the code was executing. Whether a null value is valid is entirely
> dependent on the logic of the code using it and so often cannot be
> checked at compile time.

It is very difficult to check for:
    method requiring non null parameter called with null

But I think the typical check is:
    method requiring non null parameter called with something that is 
not guaranteed to be non null

I don't think I would mind it if it got build into the language and
was checked by the compiler. That would just be additional type safety.

But I am not keen on relying on some tool having been run with no
way to verify if it has.

Arne

[toc] | [prev] | [next] | [standalone]

#36988

On Sat, 8 Jul 2017 21:14:59 -0000 (UTC), Martin Gregorie wrote:

> On Sat, 08 Jul 2017 22:33:36 +0200, Joerg Meier wrote:
>> On Fri, 7 Jul 2017 12:12:04 -0400, Arne Vajhøj wrote:
>>> I don't like to rely on IDE/checktool to enforce integrity of
>>> application.
>> Why not ? You presumably let a tool do your type checking for you all
>> the time. Where is the difference to null checking ?
> I'm with Arne here.

I don;t want to argue with opinions, but ...

> Type checking can generally be done at compile time because its static 
> w.r.t code statements. 

> However, the same doesn't apply to null checks. Whether a reference 
> variable contains null or not depends on what has been assigned to it 
> while the code was executing. Whether a null value is valid is entirely 
> dependent on the logic of the code using it and so often cannot be 
> checked at compile time.

But we are literally discussing a tool/specification here that makes it
possible to do exactly that. I get not wanting to rely on it*, but it's
weird to argue that this tool basically doesn't exist. Null checks can
easily be done at compile time by using these tools.



Liebe Gruesse,
		Joerg
		
*:  I don't really get it, I mean, I rely on all kinds of things as part of
my build process like unit tests, packaging, resource bundling and
transformations, etc. I don't write runtime checks to see if libraries are
present on the class path, because I trust my build tool to include them,
and I don't really see why I should trust my build tool in this task but
not in another.

[toc] | [prev] | [next] | [standalone]

#36992

On Tue, 25 Jul 2017 07:26:39 +0200, Joerg Meier wrote:

> But we are literally discussing a tool/specification here that makes it
> possible to do exactly that. I get not wanting to rely on it*, but it's
> weird to argue that this tool basically doesn't exist. Null checks can
> easily be done at compile time by using these tools.
>
As I said earlier, I was writing C long before I started using Java and 
am still writing quite a bit of C: which language I use depends on the 
sort of task and what the target hardware is [*].

Of course YMMV, but it makes sense for me to make these checks explicit 
in Java because that's what I'm used to doing in C.

[*] I considered writing an 8-bit emulator in Java. Some parts, including 
configurable modularity, would have been really easy in Java, but making 
8 bit register handling  (which required 8 bit unsigned arithmetic plus a 
setting the CC register on overflow, whether bit 0 was set, etc,etc 
turned out to be much easier in C. OTOH a tool for setting up a set of 
club duty rosters was a breeze in Java and would have been bad news in C.
 

-- 
martin@   | Martin Gregorie
gregorie. | Essex, UK
org       |

[toc] | [prev] | [next] | [standalone]

#36838

On 7/8/2017 4:33 PM, Joerg Meier wrote:
> On Fri, 7 Jul 2017 12:12:04 -0400, Arne Vajhøj wrote:
>> I don't like to rely on IDE/checktool to enforce
>> integrity of application.
> 
> Why not ? You presumably let a tool do your type checking for you all the
> time. Where is the difference to null checking ?

Checks done by the Java compiler are fine, because if the byte code
exist then I assume that it has been through a compliant Java
compiler.

Checks done by a tool to provide input for refactoring are fine.
You can run the tool and make some fixes and the code is going
to be better.

Checks done by a tool to have runtime checks replaced by
build time checks leave me with a fuzzy feeling. Will that
tool always be run? Can I verify if it has been run?
That is why I don't want to rely on a tool for this
type of stuff.

Arne

[toc] | [prev] | [next] | [standalone]

#36845

On Saturday, July 8, 2017 at 6:21:14 PM UTC-4, Arne Vajhøj wrote:
> Checks done by the Java compiler are fine, because if the byte code
> exist then I assume that it has been through a compliant Java
> compiler.
> 
> Checks done by a tool to provide input for refactoring are fine.
> You can run the tool and make some fixes and the code is going
> to be better.
> 
> Checks done by a tool to have runtime checks replaced by
> build time checks leave me with a fuzzy feeling. Will that
> tool always be run? Can I verify if it has been run?
> That is why I don't want to rely on a tool for this
> type of stuff.
> 
> Arne

I'm just talking about a public method.  I don't normally check for nulls in private method because I know where the value comes from and if it might be or should be allowed a null.  Once I compile it into a jar and someone else calls the method we have no idea.  They could decide a null ought to be acceptable and explicitly pass it, or they could pass a variable that accidentally gets assigned a null value.  I just want the method to crash as soon as possible with the "invalid parameter" exception.  Objects.requireNonNull() is now the simplest way to do that, and in this case the @NonNull appears pointless?

[toc] | [prev] | [next] | [standalone]

#36843

On 07.07.2017 18:12, Arne Vajhøj wrote:

> You need to choose between approaches:
> 1) Annotate and let IDE/checktool give you warnings during dveelopment
> 2) Make a runtime check
>     A) Insert the check code manually
>     B) Annotate and weave the check code in via AOP

> I think approach 2A is the simple safe approach.

Often the manual insertion is not necessary because the first method 
invoked will trigger a NPE.  I tend to add explicit null checks

* For methods when an argument is assigned a member variable which by 
class invariant must not be null and which does not invoke methods on 
the argument.  This is often the case for constructors.
* If the automatic null check on method invocation comes too late (e.g. 
when the work of the method is half through at the time and would 
require rolling back work).  I also like to do argument checks like 
these before a synchronized block is entered.

Kind regards

	robert

-- 
remember.guy do |as, often| as.you_can - without end
http://blog.rubybestpractices.com/

[toc] | [prev] | [next] | [standalone]

#36818

On 7/7/2017 11:54 AM, Eric Douglas wrote:
> On Friday, July 7, 2017 at 11:50:05 AM UTC-4, Arne Vajhøj wrote:
>>
>> I am not sure that I understand the question.
>>
>> Annotations can be used by compilers or check tools to
>> issue warnings/errors and by AOP tools to insert runtime checks
>> automatically.
>>
>> A runtime check is just a piece of code that does a runtime check.
>>
>> Two completely different purposes.
>>
>> Arne
> 
> So what are you trying to say, if you need a parameter to never be null use both the @NonNull and the new Objects.requireNonNull()?
> Is the assert verb still necessary or useful?

     See Arne's response. I'll just add that `assert' is not
suitable for sanity-checking arguments to public methods, for
the very simple reason that

	I T   C A N   B E   T U R N E D   O F F

... and in fact *is* turned off by default unless you ask the
JVM to enable it.

     `assert' is for catching logic errors in the code, not invalid
data from "external sources."  What counts as "external" is a bit
fuzzy, and some arguments (particularly of `private' methods) may
well count as "internal" and be appropriate for `assert' tests.
But if you require a reference to be non-null or a number to be
non-negative or a String to be exactly seven characters long, you
should enforce your requirement with something stronger than `assert'.

-- 
esosman@comcast-dot-net.invalid
Twelve hundred ninety-three days to go.

[toc] | [prev] | [next] | [standalone]

#36999

On Friday, July 7, 2017 at 9:53:41 AM UTC-7, Eric Sosman wrote:
> On 7/7/2017 11:54 AM, Eric Douglas wrote:
> > On Friday, July 7, 2017 at 11:50:05 AM UTC-4, Arne Vajhøj wrote:
> >>
> >> I am not sure that I understand the question.
> >>
> >> Annotations can be used by compilers or check tools to
> >> issue warnings/errors and by AOP tools to insert runtime checks
> >> automatically.
> >>
> >> A runtime check is just a piece of code that does a runtime check.
> >>
> >> Two completely different purposes.
> >>
> >> Arne
> > 
> > So what are you trying to say, if you need a parameter to never be null use both the @NonNull and the new Objects.requireNonNull()?
> > Is the assert verb still necessary or useful?
> 
>      See Arne's response. I'll just add that `assert' is not
> suitable for sanity-checking arguments to public methods, for
> the very simple reason that
> 
> 	I T   C A N   B E   T U R N E D   O F F
> 
> ... and in fact *is* turned off by default unless you ask the
> JVM to enable it.
> 
>      `assert' is for catching logic errors in the code, not invalid
> data from "external sources."  What counts as "external" is a bit
> fuzzy, and some arguments (particularly of `private' methods) may
> well count as "internal" and be appropriate for `assert' tests.
> But if you require a reference to be non-null or a number to be
> non-negative or a String to be exactly seven characters long, you
> should enforce your requirement with something stronger than `assert'.

`assert` is active documentation for algorithmic invariants. Its main purpose is to assert (hence the name) that an invariant holds. To use it correctly, one has to know what an invariant is and why it's important.

-- 
Lew

[toc] | [prev] | [next] | [standalone]

#37001

On Wednesday, July 26, 2017 at 2:17:07 PM UTC-4, lewb...@gmail.com wrote:
> `assert` is active documentation for algorithmic invariants. Its main purpose is to assert (hence the name) that an invariant holds. To use it correctly, one has to know what an invariant is and why it's important.
> 
> -- 
> Lew

I'm still not sure if or when assert is necessary.  I have it in one line of my API, and another class that was copy and pasted from that, and I don't recall if I came up with that or pasted that code from the web.

Would this be a valid use of assert?
http://www.programcreek.com/java-api-examples/index.php?source_dir=lsml-master/src/lisong_mechlab/view/ItemTransferHandler.java

This looks like where I may have copied from:
https://stackoverflow.com/a/4769575/6927352

[toc] | [prev] | [next] | [standalone]

#37002

On 7/26/2017 2:40 PM, Eric Douglas wrote:
> [...]
> Would this be a valid use of assert?
> [A method asserts that it is running on the Event Dispatch Thread]

     "Bless you, it all depends!" -- Pitti-Sing

     Specifically, it depends on your attitude towards calling the method
on an unsuitable thread: Would that be a "bug" or a "mistake?"  If the
call occurs on the wrong thread, is it because something has gone wrong
in the program's logic ("bug"), or because the programmer was ignorant
or perhaps careless ("mistake")?  In the "bug" case an `assert' seems
entirely appropriate, whereas for a "mistake" it would probably be
better to throw something like an IllegalStateException.

     Bear in mind that `assert' can be disabled without recompiling,
and is in fact disabled unless explicitly enabled at run-time.  Thus
it is more suited to a debugging situation than to a defensive one;
you'd enable `assert' during testing and fix the bugs it highlights,
then leave it "latent" in the code in case mysteries arise after
deployment and you'd like to turn it back on again.  But you would
not use `assert' to check that a user's input is valid, or that a
particular file is accessible, or anything else that is not already
under the program's control.

     The code you link to lies in a gray area: You can debug your own
use of it until you're satisfied all is well, but that's not the end
of the tale.  The code is a `protected' method of a `public' class,
meaning that other programmers can extend the class and call the
method -- and perhaps call it inappropriately.  Your tests never saw
their faulty code, and the `assert' is turned off until somebody
thinks to turn it back on again, and ...  In this case, a test that
will *always* be there and *always* fire may be appropriate.  This
may be a case where IllegalStateException would be preferable.

     ... but then again, maybe not.  "It all depends!"

-- 
esosman@comcast-dot-net.invalid
Twelve hundred seventy-four days to go.

[toc] | [prev] | [next] | [standalone]

#37019

Have you read up on algorithmic invariants?

[toc] | [prev] | [next] | [standalone]

Page 1 of 2  [1] 2  Next page →

Back to top | Article view | comp.lang.java.programmer

csiph-web