Здравствуйте, peer, Вы писали:
P>Зачем нужен try-catch в TDD
[кэп]
Когда в контракт проверяемого кода входит определённое поведение в исключительных ситуациях. Например, словарь должен бросать KeyNotFoundException при попытке получить значение по отсутствующему ключу. Или, наоборот, код не должен бросать исключения с деталями внутренней реализации типа NullReferenceException при попытке сохранить картинку.
[/кэп]
Здравствуйте, peer, Вы писали:
P>Ведь тестами должно всё покрываться. P>Или я что-то не понимаю.
Во-первых, все тестами покрыть нельзя. Они, по идее, изолированные
и взаимодействие с реальным миром мокируется. А реальный мир бывает суров...
Не оказалось файла или кто-то случайно удалил, примеров можно привести массу.
Здравствуйте, peer, Вы писали: P>Ведь тестами должно всё покрываться. P>Или я что-то не понимаю. P>в TDD новичок
вот ты едешь на машине, у тебя колесо спускает. это ошибка или исключительная ситуация?
Здравствуйте, __kot2, Вы писали:
__>Здравствуйте, peer, Вы писали: P>>Ведь тестами должно всё покрываться. P>>Или я что-то не понимаю. P>>в TDD новичок __>вот ты едешь на машине, у тебя колесо спускает. это ошибка или исключительная ситуация?
но тут как бы 2 случая: проткнулось и резко спустилось или же равномерно спускалось само.
во втором случае может помочь датчик давления в шинах и тут тест делать надо на него.
а первый случай — исключительна ситуация сравним с тем, что во время работы программы произойдет выключение питания и трай-кетч тоже не поможет.
Здравствуйте, peer, Вы писали: P>но тут как бы 2 случая: проткнулось и резко спустилось или же равномерно спускалось само. P>во втором случае может помочь датчик давления в шинах и тут тест делать надо на него. P>а первый случай — исключительна ситуация сравним с тем, что во время работы программы произойдет выключение питания и трай-кетч тоже не поможет. P>поправьте если не прав
во время любой операции может произойти вероятная ошибка.
пытаетесь достать домкрат, а домкрата нет или он намертво закис или резьба сорвалась от частого использования — это все вероятные события, которые помешают вам выполнить то, что вы хотите, но для вашей логики это в общем-то не важно — у вас у операции поменять колесо есть ДомкратЭксепшен, который обрабатывается поиском нового домкрата. если вы будете городить обработку ошибок с домкратом ифами прямо в логике замены колеса будет криво и вообще не в тему. вместо того, чтобы продолжать работу по замене колеса можно на любом этапе кинуть эксепшен, прервать всю работу и полностью перейти от замены к колеса к поиску домкрата.
вот что такое исключение.
а ошибка это когда вы пытаетесь воспользоваться домкратом, а у вас руки отваливаются, домкрат взрывается и убивает вас. вот этого быть вообще не должно.
Здравствуйте, __kot2, Вы писали:
__>Здравствуйте, peer, Вы писали: P>>но тут как бы 2 случая: проткнулось и резко спустилось или же равномерно спускалось само. P>>во втором случае может помочь датчик давления в шинах и тут тест делать надо на него. P>>а первый случай — исключительна ситуация сравним с тем, что во время работы программы произойдет выключение питания и трай-кетч тоже не поможет. P>>поправьте если не прав __>во время любой операции может произойти вероятная ошибка. __>пытаетесь достать домкрат, а домкрата нет или он намертво закис или резьба сорвалась от частого использования — это все вероятные события, которые помешают вам выполнить то, что вы хотите, но для вашей логики это в общем-то не важно — у вас у операции поменять колесо есть ДомкратЭксепшен, который обрабатывается поиском нового домкрата. если вы будете городить обработку ошибок с домкратом ифами прямо в логике замены колеса будет криво и вообще не в тему. вместо того, чтобы продолжать работу по замене колеса можно на любом этапе кинуть эксепшен, прервать всю работу и полностью перейти от замены к колеса к поиску домкрата.
Поиск нового домкрата как раз не делал никогда. Писал в лог и исправлял баг. Возможно не имел дело со сложными операциями.
__>вот что такое исключение. __>а ошибка это когда вы пытаетесь воспользоваться домкратом, а у вас руки отваливаются, домкрат взрывается и убивает вас. вот этого быть вообще не должно.
С этим понял. Тогда встает вопрос, который не так прост: как формировать блоки try-catch?
сейчас делаю достаточно примитивно: оборачиваю клик кнопки, а вся работа в бизнес логике, обращения в базу не оборачивается.
Здравствуйте, peer, Вы писали: P>С этим понял. Тогда встает вопрос, который не так прост: как формировать блоки try-catch?
а их не надо писать сначала.
просто рано или поздно вы наткнетесь на то, что операция легко может быть не завершена по какой-то причине
например, нет соединения с сервером, какие-то параметры неправильные или другой человек уже что-то поменял в другом месте
и у вас возникнет вопрос — где ошибку обрабатывать.
самый простейший вариант это конечно записать ее в лог и подавить. так что код пишут.
такие приложения работают очень загадочно — жмешь на кнопку, ничего не происходит, потом бац, что-то странное поменялось, перекосило, заглючило, закрыл, открыл заново, пишет какую-то странную ошибку.
не надо ошибки подавлять. особенно грустно когда ошибка подавляется при инициализации какого-то класса в дурацком методе типа init, а класс обрабатывается как полностью инициализированный и рабочий.
ошибки надо наверх проталкивать ровно до того места, когда станет понятно что с ними делать
для простого приложения с UI часто достаточно просто вывести ошибку пользователю.
в этом случае чтобы не копипастить код вывода ошибок вокруг каждой кнопки можно запихать этот код туда, где он будет автоматом вызван при любом действии и при этом может воздействовать на UI
если у нас специфическая ошибка для конкретного действия, то можно в это конкретное действие try-catch вставить
главное не пытаться обрабатывать исключение там, где непонятно что с ним делать
