О проверке входных параметров, принятой в 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

[bydl0coder.livejournal.com]

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

[metaclass.livejournal.com]

Ну, я ж с C# и пришел - там везде проверки и ArgumentException, а тут в жабах бардак какой-то. "Циклы экономят". Один cmp/jne вызов, ага.

[jdevelop.livejournal.com]

ребе, assert и -ea