Использование аннотации, чтобы гарантировать, что значение, возвращаемое методом, не будет отброшено

Вы также можете проверить jsr305, он определяет @CheckReturnValue. Он совместим с findbugs и генерирует предупреждение, когда кто-то забывает обработать возвращаемое значение.

Guavas Splitter использует его: http://code.google.com/p/guava-libraries/source/browse/guava/src/com/google/common/base/Splitter.java

Должен сказать, что я люблю аннотации, которыми можно руководствоваться при статическом анализе кода.

Я не уверен в осуществимости — особенно в переносном виде — но взгляните на Римские цифры в нашей Java (код GitHub) от Адриана Куна. Он использовал обработку аннотаций И частный API Sun javac для добавления литералов римских цифр в Java путем посещения исходного кода для замены.

Возможно, вы могли бы использовать аналогичный подход к:

• найти вызовы вашего аннотированного метода в исходном коде
• check if the result is assigned (won't be easy IMO)
  • generate a compiler warning if not

И не пропустите следующие ресурсы из поста Адриана:

Вам также может понравиться

• Руководство хакера по компилятору Java Дэвида Эрни
• Ресурсы Javac Hacker, набор ссылок
• Как переписать утверждения так, чтобы их нельзя было отключить!

Ссылка

• римские цифры в нашей Java
• Код GitHub

Похожие вопросы

• Подключение к компиляторам Java
• Как намеренно вызвать предупреждающее сообщение пользовательского компилятора Java?< /а>
• Как создать пользовательскую аннотацию и обработать ее с помощью АПТ?

В заключение: вы хотели бы иметь @Deprecated как аннотацию, которая поможет компилятору/IDE предупреждать/ошибки, когда метод вызывается без присвоения его результата? Вы не можете добиться этого без изменения исходного кода Java и компилятора. Конкретный метод должен быть аннотирован, и компилятор должен знать о них. Не изменяя исходный код и/или компилятор, вы можете в лучшем случае создать тип плагина/настройки IDE, который распознает случаи и соответственно генерирует ошибку/предупреждение.

Обновление: вы можете написать вокруг него фреймворк/плагин, который соответственно проверяет вызываемый метод и ошибки. Вы хотели бы, чтобы аннотация была доступна только во время выполнения. Вы можете сделать это, аннотировав аннотацию с помощью @Retention (RetentionPolicy.RUNTIME). Затем вы можете использовать Method#getAnnotation(), чтобы определить, доступна ли эта аннотация. Вот начальный пример того, как такая структура может выполнять эту работу:

package com.example;

import java.lang.annotation.Retention;
import java.lang.annotation.RetentionPolicy;

public class Test {

    public static void main(String[] args) throws Exception {
        if (Test.class.getMethod("f", new Class[0]).getAnnotation(Undiscardable.class) != null) {
            System.err.println("You should not discard the return value of f()!");
        } else {
            f();
        }

        System.out.println(f());
    }

    public static @Undiscardable int f() {
        return 42;
    }
}

@Retention(RetentionPolicy.RUNTIME)
@interface Undiscardable {}

Тем не менее, чтобы заставить компилятор выполнять эту работу, вам нужно проделать немного больше работы.

На Android вы можете использовать @CheckResult, чтобы показать предупреждение, если возвращаемое значение не используется.

public class ImmutableObject {

    public final int value;

    public ImmutableObject(int value) {
        this.value = value;
    }

    @CheckResult
    public ImmutableObject addOne() {
        return new ImmutableObject(value + 1);
    }
}

Это выдаст предупреждение:

ImmutableObject obj = new ImmutableObj();
obj.addOne();  // Warning here
ImmutableObject obj2 = obj.addOne();  // No warning

Если вы используете RxJava, вы также можете использовать @CheckReturnValue.

Вам не нужно определять аннотацию. Вы можете определить правило при вызове метода:

1. метод имеет возвращаемый тип void;
2. результат метода используется в качестве аргумента для вызова другого метода; или
3. результат метода присваивается переменной.

Вы можете реализовать процессор, который применяет это правило, или реализовать контрольный стиль, который применяет это правило.

Отказ от ответственности: на самом деле, у меня тот же вопрос, но еще не полное решение. НО:

У меня есть идея, как это можно сделать чистым способом, которую я хочу опубликовать здесь, пытаясь это сделать:

1. One may use AspectJ to invoke code after a specific method has been called. For example

   @AfterReturning(pointcut=“call(int Foo.m(int))”, returning=”x”)
   public void doSomething(int x){ ... }

   could be used. The return value x is passed to your method.

2. Затем ваш метод может отслеживать счетчик ссылок возвращаемого значения. Если возвращаемое значение Garbadge Collected, оно было выброшено, и вы можете выдать предупреждение, см., например, http://java.dzone.com/articles/letting-garbage-collector-do-c

Конечно, я бы предпочел поддержку аннотации и времени компиляции для этого, поскольку вышеизложенное, возможно, подходит только для среды тестирования и, возможно, не для производства (из-за влияния на производительность).

Любые комментарии, если это может работать?

У вас есть проблема, и проблема в том, что люди могут по ошибке забыть использовать возвраты методов. Используя аннотации, вы сообщаете разработчику библиотеки, что он должен нести ответственность за напоминание своим вызывающим объектам о том, что не следует отбрасывать результаты определенных методов.

Хотя это кажется хорошей идеей, я так не думаю. Хотим ли мы загромождать код уведомлениями пользователей об их плохой практике? Существует множество продуктов, которые смотрят на код и сообщают вам, когда вы делаете что-то неправильное (или нежелательное), например, Lint, Sonar и даже в меньшей степени JavaDocs.

Что, если вы не согласны с тем, что сказал автор библиотеки, должны ли мы теперь использовать @SuppressWarnings("return-discarded").

Хотя это может быть полезно в качестве учебного пособия, моя точка зрения больше связана с разделением задач, чем с помощью начинающих программистов. Код (и аннотации) в классе должен быть связан с функцией класса, а не устанавливать политику того, когда и как использовать его методы.