Reimplement Return Value Warning #6

New Issue

delvh · 2021-02-17T12:15:25+01:00

delvh commented

2021-02-17 12:15:25 +01:00

While I understand not throwing a RuntimeException when a non-void return type has been supplied,
I'd argue that it is still useful to supply a warning in the Annotation Processor, as this return value will not be usable anyhow.

While I understand not throwing a RuntimeException when a non-void return type has been supplied, I'd argue that it is still useful to supply a warning in the Annotation Processor, as this return value will not be usable anyhow.

kske was assigned by delvh

2021-02-17 12:15:25 +01:00

kske added the

enhancement

label 2021-02-17 12:42:28 +01:00

kske commented

2021-02-17 12:48:45 +01:00

That's a good idea, however we have to find a way of suppressing the warning if a non-void return type actually has to be used, for example when retrofitting code to utilize event handling.

delvh commented

2021-02-17 13:04:46 +01:00

The problem with that is: If you really want to, you can return a List<?> (because you can have multiple listeners to the same event) but that seems not useful at all. I think it's much more useful to dissolve the return value silently.

The problem with that is: If you really want to, you can return a `List<?>` (because you can have multiple listeners to the same event) but that seems not useful at all. I think it's much more useful to dissolve the return value silently.

kske commented

2021-02-17 13:09:56 +01:00

Agreed, but how would you go about suppressing the warning? Define a custom warning string to use in @SuppressWarnings, or just introduce parameters for the processor? I will have a look into that.

Agreed, but how would you go about suppressing the warning? Define a custom warning string to use in `@SuppressWarnings`, or just introduce parameters for the processor? I will have a look into that.

delvh commented

2021-02-17 13:18:09 +01:00

If it is possible to add a custom warning for SuppressWarnings I'd prefer that

If it is possible to add a custom warning for `SuppressWarnings` I'd prefer that

delvh commented

2021-02-17 13:20:33 +01:00

Oh, I guess in that case you "simply" have to check whether the SuppressWarnings annotation is present and contains the value unused-return or something similar.
The question is if there is a method to let Eclipse handle this for you…

Oh, I guess in that case you "simply" have to check whether the SuppressWarnings annotation is present and contains the value `unused-return` or something similar. The question is if there is a method to let Eclipse handle this for you…

kske commented

2021-02-17 13:26:33 +01:00

The check is not the problem. The problem is, that Eclipse and probably other compilers as well would warn the user about the unhandled warning token, which would leave the user with yet another warning.

There isn't much information about that online, apart from this ancient Eclipse bug that doesn't appear to be solved.

The check is not the problem. The problem is, that Eclipse and probably other compilers as well would warn the user about the unhandled warning token, which would leave the user with yet another warning. There isn't much information about that online, apart from this [ancient Eclipse bug](https://bugs.eclipse.org/bugs/show_bug.cgi?id=122475) that doesn't appear to be solved.

kske commented

2021-02-17 13:27:12 +01:00

I will try implementing this and get back to you with the results.

kske commented

2021-02-17 13:38:03 +01:00

I have implemented it and it behaves exactly as I thought:

I can detect the @SuppressWarnings("unused-return") on the method and thus hide the warning, but simultaneously get an "Unsupported @SuppressWarnings("unused-return")" from my compiler.

A solution to this would be to change the problem severity on the compiler warnings, but that obviously affects more than just that specific annotation.

I have implemented it and it behaves exactly as I thought: I can detect the `@SuppressWarnings("unused-return")` on the method and thus hide the warning, but simultaneously get an "Unsupported `@SuppressWarnings("unused-return")`" from my compiler. A solution to this would be to change the problem severity on the compiler warnings, but that obviously affects more than just that specific annotation.

kske commented

2021-02-20 21:20:27 +01:00

The @SuppressWarnings thing isn't easily solvable as of yet, so any user that wants to remove the warning should just suppress it from their IDE.

The `@SuppressWarnings` thing isn't easily solvable as of yet, so any user that wants to remove the warning should just suppress it from their IDE.

kske referenced a pull request that will close this issue

2021-02-20 21:20:42 +01:00

Additional Warnings in Event Bus Proc #8

kske closed this issue

2021-02-20 21:46:08 +01:00

kske added the

proc

label 2021-02-20 22:21:43 +01:00