Community
Participate
Working Groups
program prog function main() try throw new jzs{other = 1, message = "test"}; arr2 string[]; arr2.resize(-1); onException(ex anyexception) syslib.writestdout(ex.message); end end end record jzs type exception other int; end Get a compile error in the generated code - the 'arr2' code is unreachable.
There is no logic in the generators to remove code after a return or throw type statement. I am not sure that we need to do that in the first place. This seems to be a user error, as the testcase has coded EGL statements after an unconditional throw statement. Are you expecting something different?
There's no validation error, and in some of the other cases of unreachable code validation only adds a warning. For example: exit program; SysLib.writeStdout("unreachable"); Either validation should treat this as an as error, or the generators should skip generating the statements after the throw statement if it's going to cause a problem (e.g. the javascript language doesn't care, the extra statements are ignored, so jsgen wouldn't need to change).
Personally I'd like to see the compiler put a warning on all unreachable statements. And if you generate anyway, you may have problems.
I asked Brian about this. He said let's think about it for the next release, so I'm setting the target to Future.
I just hit this same problem. The program has a statement that can never get executed. In RBD, the generated Java has a warning: dead code. But I can still debug and run the generated Java. In RBD, the generated Java has an error: unreachable code. And I can't debug or run the program. Future??
Brenda, Did you accidentally write unreachable code, or were you testing what happens when unreachable code is written? Given the current list of defects, I believe that handling unreachable code should be resolved after we have our green threads working (e.g. valid code), and after we have enabled a significant portion of the SVT test cases. We may not wait until after .7 ships to deal with this issue, but I don't think it is something we will look at in the next 2 or 3 weeks. [NOTE: I reserve the right to change my thoughts on this matter if we find that 9 out of 10 application developers are hitting this problem accidentally ;) ]
Yes, Future. When the EGL program contains unreachable code, that's a programming error. Eventually we may put in something to deal with the programmer's mistake, but it's not a priority right now. If the EGL program didn't have unreachable code, but the generated Java did, then that would be a defect worth fixing today.
Sounds like a challenge to me. :-)
*** Bug 359363 has been marked as a duplicate of this bug. ***
Deferring to Future. This won't be done in 0.8.2.
