Submitting a JEP

[Mario Torre]

I'm reading the proposal a bit and I don't think it's a very good idea
to introduce another keyword.

While it may be nice to have such statement, effectively you are
promoting bad programming use cases.

If we take the stack overflow link as an example, it's clear that the
developer could simply rearrange his code to be more stable by using
some of the advanced features of Java like classes and inheritance ;)
or at worse by just documenting the need to add the return after the
else branch

In all the other examples you give in the proposal, unless I'm
misreading them, it seem that they are not unreachable statements in a
sense that can the statically defined, but are simply cases that the
developer "knows" they won't happen, but they may, and so they can be
solved by an assert or by a runtime exception.

So the only use case I see is the stack overflow one, but it seems to
me this is just bad code practices, which is branching points with
multiple return statements, that is always asking for troubles.

In the short term future we will get enhanced switches with patterns,
which turns switches into expression, and it makes the stack overflow
example a lot easier to write without side effects.

Cheers,
Mario

2017-10-06 16:30 GMT+02:00 Daniel Trebbien <dtrebbien at gmail.com>:
> On Fri, Oct 6, 2017 at 7:24 AM, David Lloyd <david.lloyd at redhat.com> wrote:
>
>> On Thu, Oct 5, 2017 at 10:17 PM, Brian Goetz <brian.goetz at oracle.com>
>> wrote:
>> > The proposal is a bad fit for the assertion facility, since the assertion
>> > facility is designed to be disabled, and what you want is something that
>> > can't be disabled.
>>
>> I believe that in the document, Mr. Trebbien explicitly explained why
>> the assertion facility is a bad fit, and was specifically not
>> suggesting it be used, but rather using it as an example and template
>> for the new feature.
>>
>
> Specifically, in the Alternatives section (
> https://github.com/dtrebbien/JEP-Unreachable-Assertions/blob/master/jep.md#alternatives
> ), I discuss why neither allowing the proposed "unreachable assertions" to
> be disabled, nor amending §14.21 Unreachable Statements to allow
> unreachable `assert false' statements, is preferred.
>
> The JLS specifies in §14.10 that an assertion is either enabled or
> disabled.  However, the JLS does not specify how assertions are enabled or
> disabled.
>
> Unless I am mistaken, there is no standard way to guarantee that assertions
> compiled into a CLASS file will be disabled at runtime.  Therefore, unless
> the distributor of Java software uses some sort of post-compilation
> assertion stripping from CLASS files, the programmers must assume that
> assertions might be enabled at runtime.
>
>> But here's an alternative:
>> >
>> >     throw new UnreachableAssertionException("why");
>> >
>> > This doesn't need a language feature.
>>
>> It does, because you cannot put "throw" statements in places where the
>> compiler has statically determined that control flow cannot reach,
>> which is a key part of the justification of the feature described in
>> the document.
>>
>> This is a feature that I for one have sorely missed for many years
>> now, especially in more complex state-oriented code where exit points
>> cannot be made visually clear.
>>
>
> Yes.  §14.21 Unreachable Statements requires unreachable statements to be
> compile-time errors, so you currently cannot place a statement like `throw
> new UnreachableAssertionException("why");' at points defined to be
> unreachable.



-- 
pgp key: http://subkeys.pgp.net/ PGP Key ID: 80F240CF
Fingerprint: BA39 9666 94EC 8B73 27FA  FC7C 4086 63E3 80F2 40CF

Java Champion - Blog: http://neugens.wordpress.com - Twitter: @neugens
Proud GNU Classpath developer: http://www.classpath.org/
OpenJDK: http://openjdk.java.net/projects/caciocavallo/

Please, support open standards:
http://endsoftpatents.org/