![[personal profile]](https://www.dreamwidth.org/img/silk/identity/user.png){kind=small}
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:![[livejournal.com profile]](https://www.dreamwidth.org/img/external/lj-userinfo.gif)
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:
artureg упорно убеждает меня, что "пусть валится", потому что проверка должна быть "в другом слое". Судя по всему, все разработчики думают, что обработка ошибок должна быть в другом слое :)
![[identity profile]](https://www.dreamwidth.org/img/silk/identity/openid.png){kind=small}
no subject
Date: 2012-10-10 08:15 am (UTC)По идее, вполне возможно задокументировать NPE как валидную ошибку в методе (@throws NullPointerException if ... are null) и это ВАША проблема, почему вы не прочитали жавадок.
Все эти тривиальные проверки тратят циклы и от них желательно избевляться на верхних уровнях. Для этого в яве экспериментально например сделали @NotNull / @Nullable аннотации и лёгкий inference. Естественно кложа не даёт такого. Что сказать, ну такой язык. Я посмотрел -- неадекват.