Я хотел бы иметь какой-то механизм быстрого отказа от проекта (возможно, RuntimeException) для любого кода, который вызывает назначение NaN.Java-математика - тестирование для NaN
В моем проекте NaN никогда не будет действительным значением.
Я понимаю, что могу добавить утверждения (используя isNaN) или другие тесты, но я хочу знать, есть ли более элегантный способ.
Да, вы можете использовать AspectJ (аспектно-ориентированное программирование), чтобы вызывать ошибку, когда значение установлено на NaN.
По существу, вы хотите перехватить всякий раз, когда задано значение, и выполнить некоторую другую функцию.
Мы сделали аналогичные вещи в нашей кодовой базе ... но я не могу дать вам много помощи за пределами этого.
Спасибо - это интересно. – Pool
Нет - потому что NaN Является допустимым значением, используя его, не будет вызывать исключения. Без каких-либо вездесущих механизмов мониторинга вам нужно будет явно проверить в тех точках, где он может быть назначен или возвращен из метода.
Если вы готовы пожертвовать работой приложения, вы можете создать оболочку для Double (или другого числового объекта, которую хотите использовать), и создать исключение, если установлено значение NaN.
Технически, можно было бы создать средство, чтобы сделать это, instrumenting код в вопросе, чтобы придать Assert или если таковые тесты автоматически. Это будет включать в себя бит проверки и преобразования байт-кода (например, с использованием ASM). По моему мнению, для этого потребуются чрезвычайные обстоятельства. Вы должны быть осторожны, чтобы не применять какие-либо классы, которые полагаются на возможность обрабатывать NaN внутренне.
Я не знаю, что кто-то написал такой агент. Если вы ищете серебряную пулю, я не думаю, что она есть.
Еще один подход - вы можете интегрировать проверки кода как PMD в свой процесс сборки и создать правило, сообщающее каждое присваивание Double.NaN.
Это не будет идеально, потому что он не может поймать NaN, который вы получаете извне (база данных, соединения) или что кто-то создает с помощью манипуляции с битами, но по крайней мере вы можете гарантировать, что Double.NaN не может быть присвоено переменной или использоваться как параметр метода или внутри оценки.
Определение правил может быть сложным - но по крайней мере - это другой подход. Самое простое правило - запретить вообще Double.NaN.
Что вы на самом деле планируете делать? – helpermethod
Что я хотел бы сделать, это точно знать, где сложное численное вычисление идет не так, без рассеяния 'isNaN' тестирует весь код. Во многих других средах я могу использовать ловушки IEEE 754 (http://stackoverflow.com/questions/699078/what-languages-expose-ieee-754-traps-to-the-developer), но [не на JVM ] (http://java.sun.com/docs/books/jvms/second_edition/html/Overview.doc.html#35254). –