О проверке входных параметров, принятой в Java

[metaclass]

Есть такой оккультный стек-трейс: https://gist.github.com/def1fa8666a8ac83130a.
Причина в том, что в деконструктор массивов кложури вида (let [sql & params] some-array] передан пустой массив и строка sql в таком случае становится null и оный null передается в jdbc драйвер.
Строка на которой валится NPE, выглядит следующим образом:
protected boolean checkForEscapes(String sql) {
sql = sql.toLowerCase();

А вопрос, вообще говоря, в следующем: почему никто не проверяет параметр на валидность хотя бы в одной точке входа в одной из трех либ (clojure.java.jdbc, apache dbcp или jaybird)?

Выглядит так, как будто нормальную проверку параметров на валидность на границах API в жабе делать не принято.

PS: artureg упорно убеждает меня, что "пусть валится", потому что проверка должна быть "в другом слое". Судя по всему, все разработчики думают, что обработка ошибок должна быть в другом слое :)

Comments

[artureg.livejournal.com]

судя по именам это дао леер, обычно валидация и обработка ошибок происходит выше.

[develop7]

кстати ребе М настолько суров, что гитхаб падает при попытке показать его профайл

[artureg.livejournal.com]

ксти, а зачем переводить запрос? в нижний регистр?

[jdevelop.livejournal.com]

вы знаете, раньше для меня стандартом ебанутости стектрейса был стектрейс спрингового приложения или какого-нибудь уёбложика

теперь это определенно кложура.

[volodymir-k.livejournal.com]

Вопрос о месте проверки и способе проявления ошибки непрост и может иметь разные варианты ответа.
По идее, вполне возможно задокументировать NPE как валидную ошибку в методе (@throws NullPointerException if ... are null) и это ВАША проблема, почему вы не прочитали жавадок.

Все эти тривиальные проверки тратят циклы и от них желательно избевляться на верхних уровнях. Для этого в яве экспериментально например сделали @NotNull / @Nullable аннотации и лёгкий inference. Естественно кложа не даёт такого. Что сказать, ну такой язык. Я посмотрел -- неадекват.

[zmila.livejournal.com]

в самом деле, а ты почему не проверил на nil? :)

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

[max630.livejournal.com]

А не похуй ли, в конце концов? Если код уже уехал от места где вместо null должен был быть не null, всё равно ошибку трудно искать.

И да, почему таки там null вместо пустой строки?

[andrew kondratovich (from livejournal.com)]

Имхо из апи могут сыпаться всякие SuperLibrarySomeException. Но вот не NPE...

[raydac.livejournal.com]

вот в одной крупной компании Java программист тоже подумал что кто то на другом уровне проверит, как результат 5000 девайсов на перепрошивку (проданных девайсов причем)

[chumpa.livejournal.com]

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

[juan-gandhi.livejournal.com]

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

[bydl0coder.livejournal.com]

Странный этот ваш артурег. "Пусть валится" это из руби, там принято на любые неправильные параметры реагировать NPE с километровым стектрейсом. В сишарпе я аргументы проверял почти в каждом публичном методе. Кстати, дико вот это вольное обращение с параметрами в руби и джс не нравится, в сишарпе чуть что не так - иди на хуй с ArgumentException, а в динамических либо попытаются таки понять, что ты имел в виду, либо свалятся в дебрях. И то и другое мешает отладке.