Отказ от ответственности

Во-первых, материал появился потому, что хотелось быстро объяснить индусам коллегам, что такое null-анализ, чем он хорош и почему нужно прямо сейчас преодолеть корпоративную лень и начать использовать этот анализ в проектах. Статьи, содержащей полную систематизированную информациию о предмете без привязки к IDE, не нашлось, так что пришлось писать самому. И хотя в результате полной систематизации так и не получилось, всё равно захотелось поделиться материалом с более широкой аудиторией. Будет минимум текста и много изображений.

Во-вторых, на ресурсе уже есть отличная статья tr1cks, посвящённая IntelliJ IDEA, которая усиливает и без того стойкое впечатление, что IDEA — это очень хорошо, а Eclipse — это для бедных (что стало притчей во языцех). Для соблюдения баланса я сконцентрируюсь на Eclipse.

Эта простая статья скорее для начинающих разработчиков Java, хотя я нередко вижу и опытных коллег, которые беспомощно глядят на stack trace, сообщающий о NullPointerException (сокращённо NPE), и не могут сделать никаких выводов без отладчика. Разумеется, до NPE своё приложение лучше не доводить: вам помогут null-аннотации, валидация входных параметров и другие способы. Но когда пациент уже болен, надо его лечить, а не капать на мозги, что он ходил зимой без шапки.

Итак, вы узнали, что ваше приложение упало с NPE, и у вас есть только stack trace. Возможно, вам прислал его клиент, или вы сами увидели его в логах. Давайте посмотрим, какие выводы из него можно сделать.

Disclaimer

• Статья не претендует на открытие Америки и носит популяризаторско-реферативный характер. Способы борьбы с NPE в коде далеко не новые, но намного менее известные, чем этого хотелось бы.
• Разовый NPE — это, наверное, самая простая из все возможных ошибок. Речь идет именно о ситуации, когда из-за отсутствия политики их обработки наступает засилье NPE.
• В статье не рассматриваются подходы, не применимые для Java 6 и 7 (монада MayBe, JSR-308 и Type Annotations).
• Повсеместное защитное программирование не рассматривается в качестве метода борьбы, так как сильно замусоривает код, снижает производительность и в итоге все равно не дает нужного эффекта.
• Возможны некоторые расхождения в используемой терминологии и общепринятой. Так же описание используемых проверок Intellij Idea не претендует на полноту и точность, так как взято из документации и наблюдаемого поведения, а не исходного кода.

JSR-305 спешит на помощь

Здесь я хочу поделиться используемой мной практикой, которая помогает мне успешно писать почти полностью NPE-free код. Основная ее идея состоит в использовании аннотаций о необязательности значений из библиотеки, реализующей JSR-305 (com.google.code.findbugs: jsr305: 1.3.9):

• @Nullable — аннотированное значение является необязательным;
• @Nonnull — соответственно наоборот.

Естественно обе аннотации применимы к полям объектов и классов, аргументам и возвращаемым значениям методов, локальным переменным. Таким образом эти аннотации дополняют информацию о типе в части обязательности наличия значения.

Предлагаю вашему вниманию перевод оригинальной статьи Роберта С. Мартина.

За последние несколько месяцев я попробовал два новых языка. Swift и Kotlin. У этих двух языков есть ряд общих особенностей. Действительно, сходство настолько сильное, что мне стало интересно, не является ли это новой тенденцией в нашей языкомешалке. Если это действительно так, то это тёмный путь.

Оба языка включают в себя некоторые функциональные характеристики. Например, в них обоих есть лямбды. В целом, это хорошая штука. Чем больше мы узнаем о функциональном программировании, тем лучше. Эти языки далеки от по-настоящему функционального языка программирования; но каждый шаг в этом направлении — хороший шаг.

Проблема в том, что оба языка сделали ставку на сильную статическую типизацию. Кажется, оба намерены заткнуть каждую дыру в своём родном языке. В случае со Swift – это странный гибрид C и Smalltalk, который называется Objective-C; поэтому, возможно, упор на типизацию понятен. Что касается Kotlin – его предком является уже довольно строго типизированная Java.

Я не хочу, чтобы вы думали, что я против статически типизированных языков. Я не против. Есть определенные преимущества как для динамических, так и для статических языков; и я с удовольствием пользуюсь обоими видами. Я предпочитаю динамическую типизацию, и поэтому я иногда использую Clojure. С другой стороны, я, вероятно, пишу больше Java, чем Clojure. Поэтому вы можете считать меня би-типичным. Я иду по обеим сторонам улицы — если так можно выразиться.

Дело не в том, что меня беспокоит статическая типизация Swift и Kotlin. Скорее меня беспокоит глубина статической типизации.

Активность патентных троллей в США достигла максимального уровня за все годы. Похоже, эта проблема не исчезнет сама собой, и реформа законодательства действительно необходима.

Новая патентная статистика от компании United Patents показывает, что в первом полугодии 2015 года в американских судах было возбуждено 3050 дел по патентам, из них 2075 дел возбуждено патентными троллями, которых в отчёте называют «непрактикующими юридическими лицами» (NPE).