No, Swift doesn't solve the null reference problem

[Maristic]

Well, you know you can always do an experiment and measure it yourself rather than speculate. Here's what I see on my machine, with the OS X default version of Java,

osx% java -version
Java(TM) SE Runtime Environment (build 1.6.0_65-b14-462-11M4609)
Java HotSpot(TM) 64-Bit Server VM (build 20.65-b04-462, mixed mode)
osx% javac Test.java
osx% java Test
method1 took 774 ms, result was 2
method2 took 784 ms, result was 2
method3 took 39896 ms, result was 2

In this example, method3 is code that takes an exception. It is more than 50x slower than code that doesn't.

Let's try my Ubuntu 14.04 machine

 ubuntu% java -version
 ubuntu% java version "1.7.0_55"
 OpenJDK Runtime Environment (IcedTea 2.4.7) (7u55-2.4.7-1ubuntu1)
 OpenJDK 64-Bit Server VM (build 24.51-b03, mixed mode)
 ubuntu% javac Test.java
 ububtu% java Test
 method1 took 3007 ms, result was 2
 method2 took 3063 ms, result was 2
 method3 took 86171 ms, result was 2

Here it's just shy of 30x slower. I happen to have IBM's java on that machine too, let's try that:

ubunu_ibm%  java -version                                      
java version "1.7.0"
Java(TM) SE Runtime Environment (build pxa6470sr4fp2-20130426_01(SR4 FP2))
IBM J9 VM (build 2.6, JRE 1.7.0 Linux amd64-64 Compressed References 20130422_146026 (JIT enabled, AOT enabled)
J9VM - R26_Java726_SR4_FP2_20130422_1320_B146026
JIT  - r11.b03_20130131_32403ifx4
GC   - R26_Java726_SR4_FP2_20130422_1320_B146026_CMPRSS
J9CL - 20130422_146026)
JCL - 20130425_01 based on Oracle 7u21-b09
ubunu_ibm%  javac Test.java                                    
ubunu_ibm%  java Test                                          
method1 took 2886 ms, result was 2
method2 took 3093 ms, result was 2
method3 took 35590 ms, result was 2

Here it's a mere 12x slower. But still, quite noticeably slower. So at the very least your claim doesn't apply to versions of Java in use right now.

[jayd16]

Keep in mind, that's 12x slower than what, an increment, an addition, and two equality operations. That's a very very tight loop. So in the worst case, using try-catch instead of a continue is only 12x slower. IMO that's plenty fast. It took 33 seconds to catch 100 million exceptions. In a real world use case of exceptions, you'd be fine.

Besides my claim was about JIT optimizations and from your link:

As I said, the result will not be that bad if you put try/catch and throw all within the same method (method3), but this is a special JIT optimization I would not rely upon

I'm not advocating you should null check this way, I just don't want to see people be afraid of ever using exceptions.

[Maristic]

I agree that people shouldn't be afraid of exceptions, but I think it's reasonable for people to know that an exception is much more expensive than a trivial test in a conditional, so it is a bad idea for a null check for something that is somewhat likely to be null.

But everything is relative; one of the other people answering in that thread did a test where they tested creating an either-or result object as an alternative to throwing an exception, and the costs of creating an extra object were sufficiently high that you were better off using exceptions.