http://coldfusion.com logo
Join Slack
Powered by
Here's an interesting question. This code doesn't...
# adobe
b
Here's an interesting question. This code doesn't error in Lucee but does error in Adobe.
Copy code
switch(5) {
    case 'foo':
    break;
    break;
    
}
The error is 
Only case: or default: statements may be immediately contained by a switch statement.
which makes sense (there is an extra 
break;
. So, should it error? Should the message be any different? Just curious what your take is on it.
Reply here...
a
Have you checked other languages to see if there's a precedent. I think it ought to error, for the reasons given, and I think the message is fine. Did it pinpoint the exact line that the second break was on?
JS on Chrome is interesting:
Copy code
switch(5) {
    console.log("hi")
    case 'foo':
    break;
    break;
    
}
VM150:2 Uncaught SyntaxError: Unexpected identifier 'console'
switch(5) {
    case 'foo':
    break;
    break;
    console.log("hi")
}
undefined
PHP behaves the same as PHP for equiv code.
Actually thinking about it more, the "block" for the 
case
statement could be considered "everything until the next 
case
, the 
default
, or the end of the 
switch
I guess. This looks to be what JS & PHP are doing
So I now think CF is wrong and Lucee is right.
Java:
Copy code
class TestSwitch {

    public static void main(String[] args) {
    
        switch ("notfoo") {
            case "foo":
            break;
            break;
        }
    }
}
Copy code
TestSwitch.java:8: error: unreachable statement
            break;
            ^
1 error
CFML has no concept of unreachable code being a problem though. So: not a valid parallel.
s
Java says it's an error:
Copy code
jshell> switch ( 42 ) {
   ...>     case 1: break;
   ...>     case 2: break;
   ...>     break;
   ...> }
|  Error:
|  unreachable statement
|      break;
|      ^----^
|  Error:
|  missing return statement
|  switch ( 42 ) {
|  ^--------------...
a
TIL: jshell is a thing
s
Oh, you wrote that while I was testing it too 🙂
a
ja
s
Also:
Copy code
seanc@Sean-win-11-laptop:~$ jshell
|  Welcome to JShell -- Version 19
|  For an introduction type: /help intro
🙂 With 
--enable-preview
(at least on the JDK) you can get virtual threads!
a
This woudl ahve saved me a lot of time in the past. How many 
TestXxx
classes like the above I have created over the years... I don't know 😕
(I had to google how to get out of the frickin thing though! Somewhat surprised CTRL-C or CFTRL-Z did not work)
s
Copy code
seanc@Sean-win-11-laptop:~$ jshell --enable-preview
|  Welcome to JShell -- Version 19
|  For an introduction type: /help intro

jshell> java.lang.Thread.startVirtualThread( () -> { System.out.println("Hi! I'm virtual!");} );
Hi! I'm virtual!
$1 ==> VirtualThread[#25]/runnable

jshell>
(compared to the Clojure code: 
(Thread/startVirtualThread #(println "Hi! I'm virtual!"))
-- gods, I hate Java!!
Does ctrl-d not work? That's EOF on sensible platforms 🙂
a
Ah yes it did. Cool.
s
jshell
was added in Java 9 so it's not exactly "new"...
I'm very excited about virtual threads! (project loom)
a
no, but my Java is entirely self-taught and only used to check stuff like this (and usually relies on RTFMing every second statement I type in cos I'm rubbish) I have had one Java class in production ever (and that woulda been close to 20yrs ago now)
s
I started with Java back in... '97 I think and kind of gave it up when Java 5 came out, whenever that was. I looked at it again when Java 8. Since then I've only really paid attention as far as what it takes to upgrade the JDK but I do look at the new features in each release and have a quick play (usually in a Clojure REPL).
At this point we're on JDK 18 in production (except for our legacy Lucee app still running on JDK 8!) and I'm starting to look at 19 in dev.
m
I feel like it makes sense. The first 
break
breaks out of that 
case
. So it's looking for the next 
case
or 
default
in the 
switch
, but encounters something else. It gives the same error for any statement.
b
@mtbrown That's how I originally thought about it, but when I saw how Java treats it as "unreachable code", I realized the break doesn't break out of the case, it breaks out of the entire switch! Otherwise, if the break only existed the current case, all subsequent cases that matched would also run, which isn't what happens.
e
To me, it seems that the difference is how Lucee vs AFC work with code under the hood, Lucee seems to read and then RESULT, whereas AFC seems to read line by line and report results.
b
FWIW, this is a compilation error in ACF, not a runtime error.
6 Views
Open in Slack
PreviousNext
Powered by