О проверке входных параметров, принятой в Java
Есть такой оккультный стек-трейс: 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 упорно убеждает меня, что "пусть валится", потому что проверка должна быть "в другом слое". Судя по всему, все разработчики думают, что обработка ошибок должна быть в другом слое :)
Причина в том, что в деконструктор массивов кложури вида (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:
![[livejournal.com profile]](https://www.dreamwidth.org/img/external/lj-userinfo.gif)
no subject
no subject
no subject
И что ему там не нравится, интересно.
no subject
no subject
no subject
no subject
no subject
no subject
1. если бы sql был нул оно бы упало выше
2. если оно нул надо кидать нпе :)
no subject
no subject
теперь это определенно кложура.
no subject
no subject
no subject
no subject
"The stack trace doesn’t fit in that large monitor in portrait mode. Guys, stop breaking your programs into many functions. Put all your code in one function and your stack traces will be shorter."
:)
no subject
no subject
no subject
no subject
no subject
в пределе можно 2048 строк в стеке сделать, по идее :)
no subject
Реальные функции имеют переменные на стеке. -fstack-protector, наверно, тоже какой-то оверхед на стеке имеет. Реально 40-50 вложенных функций максимум, но и за такое нужно руки отрывать.
no subject
По идее, вполне возможно задокументировать NPE как валидную ошибку в методе (@throws NullPointerException if ... are null) и это ВАША проблема, почему вы не прочитали жавадок.
Все эти тривиальные проверки тратят циклы и от них желательно избевляться на верхних уровнях. Для этого в яве экспериментально например сделали @NotNull / @Nullable аннотации и лёгкий inference. Естественно кложа не даёт такого. Что сказать, ну такой язык. Я посмотрел -- неадекват.
no subject
и да, в жабе это не принято. обычно клиент проверяет, что он отдаёт либе. а та просто использует, и если что не так, кидается эксцепшенами.
no subject
no subject
или ?
:)
no subject
no subject
И да, почему таки там null вместо пустой строки?
no subject
(let [[a b c d] [1 2 3]] [a b c d])
;[1 2 3 nil]
(let [[a b c d] []] [a b c d])
;[nil nil nil nil]
Если массив меньше, чем образец, которым его деконструируют, то соответствующие имена биндятся c nil.
Я передал пустой массив, который в итоге попал в такой деконструктор, первым параметром которого идет строка sql-запроса.
no subject
Долбаная динамика. И ведь наверняка найдётся 100500 случаев когда это именно то что надо.
no subject
Тема null в строках в жабе и дотнете - это отдельная стремная печаль, там строка - это одновременно и ссылка и значение - она иммутабельна, как значение, но является объектом-ссылкой :)
no subject
no subject
no subject
no subject
no subject
как ты будешь чинить?
no subject
no subject
no subject
no subject
no subject
no subject
что мешает мне таскать рядом с каждым значением лямбду с валидацией?
no subject
no subject
no subject