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