суббота, 12 марта 2011 г.

Не ищите ошибки там, где их нет

Человеку свойственно ошибаться. Но почему-то признать свою ошибку труднее, чем поверить в корректную работу уже отлаженных механизмов.

Вот на днях я себя в очередной раз поймал на попытке разобраться, почему подзапрос отрабатывает не правильно... а на самом деле подзапрос обрабатывал правильно. Просто в цикле, в котором отрабатывал подзапрос, я случайно поставил Break, вместо Continue… На самом деле в pl/sql циклах нет ни того, ни другого, а есть exit – аналог делфового Break. А вот аналога Continue в pl/sql нет. И вот с пылу, с жару, как-то само собой подставилось exit, который отрабатывал при условии, если подзапрос возвращал пустой набор данных.

Самое забавное в этой истории то, что в зависимости от входных параметров, подзапрос мог вернуть пустой НД в первой итерации цикла, а мог вообще не вернуть пустой НД. И, вместо того, чтобы посмотреть, почему же срабатывает exit, я какое-то время пытался найти изъян в условии where подзапроса…

Этот пост может показаться забавным, однако работая уже в коллективе с другими разработчиками я частенько наблюдаю такое и у своих коллег. Например, когда у программиста не получается добиться желаемого результата, вместо того, чтобы пересмотреть свой код внимательно и пройти по нему отладчиком, человек пытается отыскать причину своих неудач в используемой библиотеке. А не найдя – иногда доходит и до такого – пытается внести изменения в библиотеку таким образом, чтобы она работала так как нужно программисту здесь и сейчас, совсем не задумываясь над тем, что такие изменения могут повлечь за собой последствия…

0 коммент.:

Отправить комментарий

.

.