why on earth does this code throw a `NullPointerEx...

# android

[Andrew Ebling]

why on earth does this code throw a NullPointerException?

val macAddress = MacAddress.fromString(“aa:bb:cc:dd:ee:ff”)

...I’m passing a non-null value to an @NonNull Java method? What gives?!

[Andrew Ebling]

that’s android.net.MacAddress btw

[wbertan]

Do you have the stacktrace to share, please? It is that line throwing exception, or somewhere inside MacAddress implementation?

[Andrew Ebling]

java.lang.NullPointerException: MacAddress.fromString(macString) must not be null

	at <redacted>.TestLoggerTests.logTestStart opens data collection(TestLoggerTests.kt:28)
	at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
	at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
	at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
	at java.lang.reflect.Method.invoke(Method.java:498)
	at org.junit.runners.model.FrameworkMethod$1.runReflectiveCall(FrameworkMethod.java:59)
	at org.junit.internal.runners.model.ReflectiveCallable.run(ReflectiveCallable.java:12)
	at org.junit.runners.model.FrameworkMethod.invokeExplosively(FrameworkMethod.java:56)
	at org.junit.internal.runners.statements.InvokeMethod.evaluate(InvokeMethod.java:17)
	at org.junit.internal.runners.statements.RunBefores.evaluate(RunBefores.java:26)
	at org.junit.runners.ParentRunner$3.evaluate(ParentRunner.java:306)
	at org.junit.runners.BlockJUnit4ClassRunner$1.evaluate(BlockJUnit4ClassRunner.java:100)
	at org.junit.runners.ParentRunner.runLeaf(ParentRunner.java:366)
	at org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:103)
	at org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:63)
	at org.junit.runners.ParentRunner$4.run(ParentRunner.java:331)
	at org.junit.runners.ParentRunner$1.schedule(ParentRunner.java:79)
	at org.junit.runners.ParentRunner.runChildren(ParentRunner.java:329)
	at org.junit.runners.ParentRunner.access$100(ParentRunner.java:66)
	at org.junit.runners.ParentRunner$2.evaluate(ParentRunner.java:293)
	at org.junit.runners.ParentRunner$3.evaluate(ParentRunner.java:306)
	at org.junit.runners.ParentRunner.run(ParentRunner.java:413)
	at org.junit.runner.JUnitCore.run(JUnitCore.java:137)
	at com.intellij.junit4.JUnit4IdeaTestRunner.startRunnerWithArgs(JUnit4IdeaTestRunner.java:68)
	at com.intellij.rt.junit.IdeaTestRunner$Repeater.startRunnerWithArgs(IdeaTestRunner.java:33)
	at com.intellij.rt.junit.JUnitStarter.prepareStreamsAndStart(JUnitStarter.java:230)
	at com.intellij.rt.junit.JUnitStarter.main(JUnitStarter.java:58)

[mkrussel]

My guess is you are running this in a regular JUnit test and not an instrumented test.

All Android methods be default are configured to return null in these types of tests, but Kotlin believes that the method should never return null, so the intrinsic checks are throwing an exception.

[wbertan]

🤔 And the macString variable isn’t null? Like try to print its value before calling that.
Anyway, I think you are trying to run this in a Unit Test? Not sure it will work? 🤔 As the MacAddress class is from Android and not JVM, right? Did you try in an Instrumented test?

[Andrew Ebling]

ah of course - it’s the whole “you run against stubs” in unit tests

[Andrew Ebling]

many thanks for your help

[mkrussel]

I personally think they went too far with that.

Simple classes like Pair, PointF, etc should still work.

MacAddress seems to fit into that category.
Only complicated thing in it is Parcelable.

[Andrew Ebling]

I completely agree - I want to write a test for a method which takes a MacAddress as one of the arguments. Now I’m going to have to use a (less safe) String representation because I can’t create one to pass into the method call.

[dewildte]

You could make your own MacAddress class that checks the shape of the address String in its constructor. Something along the lines of building validity into the object itself.

[dewildte]

Perhaps an inline class could work too.

[dewildte]

Pushing the Android dependency to the furthest edges of the system.

[dewildte]

Provided the method that takes the address is under your control.

[dewildte]

Perhaps Roboelectric could help in the test?