Уже давно современные C++ компиляторы генерируют более эффективный код, чем это может сделать человек. Точно также, как калькуляторы давно умножают быстрее и точнее человека. Просто потому, что человек не может удержать в голове огромнейшее количество мелких деталей, которые влияют на производительность связанных с архитектурой процессора, шины данных, структурой программы, и пр. Далее, компиляторы делают очень хитрые оптимизации, которые крайне тяжело делать вручную, такие как размотки циклов.
Как вы относитесь к маленьким функциям? Я вот считаю, что другие просто не имеют права на существование. При таком отношении периодически возникают ситуации, что без поднятия исключений просто не куда. Например, надо выйти из цикла расположенного выше по стеку вызовов. Не передавать же флаг завершения, в конце концов. Или передать…
Такое ощущение, что у вас единственный критерий декомпозиции кода на функции — это размер получаемых функций. В результате получается лапша-код с которым без бензопилы исключений не справиться. Ну вот пример: откуда функция знает, что её вызывают из цикла? Да какое вообще её дело из цикла ли её вызывают, или ещё откуда? Получаем: «Ты туда не ходи, ты сюда ходи, ексепшен башка упадет, совсем мертвый будешь».
Функция должна быть самодостаточна, иметь хороший идентификатор и сигнатуру, по которой программист может понять где и как этой функцией можно и нужно пользоваться даже без заглядывания в её код. Исключения же делают интерфейс функции неявным. Программисту теперь мало посмотреть на сигнатуру, ему еще надо изучить код, чтобы понять в каких случаях какие исключения выкидываются. Это не проблема когда код был написан недавно и программист помнит это наизусть, либо когда код пишется на выброс. Но вот дальнейшая поддержка сильно усложняется.
>В последнее время распространилась одержимость рефакторингом. Доходит до того, что некоторые программисты ставят ему больший приоритет, чем более важным вещам, таким как:
>Отслеживаемость
>Поддерживаемость
Если у кода низкая «отслеживаемость» и «поддерживаемость», что что надо с этим кодом делать, если выкинуть нельзя?
Не согласен. Принципиальной разницы между 200 рублей и 200 миллионами рублей нет. Просто у всех разные аппетиты и разные возможности. Если гаишника или преподавателя поставить на должность, где дают 200 миллионов, то они их с радостью возьмут.
Вся проблема взяток в том, что народ к ним относится слишком лояльно. Взятки воспринимаются как само собой разумеющееся. У нас не будет нормального цивилизованного общества до тех пор, пока про взятку говорят «в этом нет ничего страшного»
Забавно в этом сообщении то, с каким упорством МС повторяет все свои ошибки и снова идет абсолютно тем же путем по тем же самым граблям.
Осталось только понять, при чем тут МС? Win7 — это десктопная ось и разрабатывалась она, как десктопная ось и прекрасно справляется со своими функциями в этом амплуа. То, что HP решила сделать планшет, используя десктопную ось — это проблемы HP, а не МС.
Шедевр. Можете еще не нажимать F5 в браузере, когда что-то не открывается, не надо делать вид, что вы умнее тех, кто реализовал TCP/IP или писал браузер.
Если бы Вы разрабатывали браузер, то тоже, наверное сделали бы, чтобы браузер пять раз пытался загрузить страницу перед тем, как показать пользователю ошибку, да? :))) Как думаете, почему браузеры так не поступают? Видимо, просто их разработчики паттерна не знают :)
Вот простейший пример возможных проблем: вызываем Вашим способом метод WCF сервера. Первый вызов метода возвращает подробную ошибку с хорошим описанием, что произошло, после чего прокси благополучно переходит в faulted state и мы забываем исходное исключение. Последующие вызовы генерируют исключение, что прокси находится в faulted state, с текстом которого к нам приходит клиент. Как будем разруливать ситуацию, учитывая, что в тексте результирующего исключения не содержится вообще никакой полезной информации, и исключение с полезной информацией мы благополучно проигнорировали?
ну вот даже на такой простой вещи можно сказать что вы теоретик.
ну вот даже на такой простой вещи можно сказать что у вас слабая аргументация, так как переходите на личности
Если сервер перестал отвечать, то это не означает, что мы имеем дело с кривым сервером. На GPRS соединении очень часто что-то работает не так.
Что именно работает не так?
Поэтому ваш ServerDownException во-первых, работает только в каком-то конкретном случае.
В этом и смысл. Мы обрабатываем только те ошибки, которые мы знаем, как надо обрабатывать. Непредусмотренные ошибки, которые мы не планировали обрабатывать (например, OutOfMemoryException, или AuthorizationException и пр.) не надо обрабатывать. Потому что мы ничего осмысленного в случае их возникновения сделать не сможем. Долбиться многократно в стену, надеясь, что у нас сами собой появятся права на доступ к сети, или пользователь в это время воткнет еще одну планку памяти смысла нет. Если не знаешь, что надо делать — не делай ничего. Пусть исключение дальше летит.
Во-вторых, имеет плохое название. В-третьих, непонятно как он будет реализован
Это неважно. Название просто от балды. Смыл в том, что обрабатывать надо только те ситуации, которые мы знаем, как обрабатывать.
В-четвертых, он не покрывает всех случаев, по которым сервер может не отвечать.
Вот и отлично. Что поможет нам в результате разруливать разные ошибочные ситуации в будущем при саппорте, когда ошибки не будут маскироваться и зашумляться кодом, который не был спроектирован на обработку этих ошибок, но, тем не менее, зачем-то их обработал.
Поделитесь!
А то я уже многих таких смелых видел :)
Спасибо, посмеялся :)
Такое ощущение, что у вас единственный критерий декомпозиции кода на функции — это размер получаемых функций. В результате получается лапша-код с которым без
бензопилыисключений не справиться. Ну вот пример: откуда функция знает, что её вызывают из цикла? Да какое вообще её дело из цикла ли её вызывают, или ещё откуда? Получаем: «Ты туда не ходи, ты сюда ходи, ексепшен башка упадет, совсем мертвый будешь».Функция должна быть самодостаточна, иметь хороший идентификатор и сигнатуру, по которой программист может понять где и как этой функцией можно и нужно пользоваться даже без заглядывания в её код. Исключения же делают интерфейс функции неявным. Программисту теперь мало посмотреть на сигнатуру, ему еще надо изучить код, чтобы понять в каких случаях какие исключения выкидываются. Это не проблема когда код был написан недавно и программист помнит это наизусть, либо когда код пишется на выброс. Но вот дальнейшая поддержка сильно усложняется.
>Отслеживаемость
>Поддерживаемость
Если у кода низкая «отслеживаемость» и «поддерживаемость», что что надо с этим кодом делать, если выкинуть нельзя?
Вся проблема взяток в том, что народ к ним относится слишком лояльно. Взятки воспринимаются как само собой разумеющееся. У нас не будет нормального цивилизованного общества до тех пор, пока про взятку говорят «в этом нет ничего страшного»
Осталось только понять, при чем тут МС? Win7 — это десктопная ось и разрабатывалась она, как десктопная ось и прекрасно справляется со своими функциями в этом амплуа. То, что HP решила сделать планшет, используя десктопную ось — это проблемы HP, а не МС.
Если бы Вы разрабатывали браузер, то тоже, наверное сделали бы, чтобы браузер пять раз пытался загрузить страницу перед тем, как показать пользователю ошибку, да? :))) Как думаете, почему браузеры так не поступают? Видимо, просто их разработчики паттерна не знают :)
ну вот даже на такой простой вещи можно сказать что у вас слабая аргументация, так как переходите на личности
Что именно работает не так?
В этом и смысл. Мы обрабатываем только те ошибки, которые мы знаем, как надо обрабатывать. Непредусмотренные ошибки, которые мы не планировали обрабатывать (например, OutOfMemoryException, или AuthorizationException и пр.) не надо обрабатывать. Потому что мы ничего осмысленного в случае их возникновения сделать не сможем. Долбиться многократно в стену, надеясь, что у нас сами собой появятся права на доступ к сети, или пользователь в это время воткнет еще одну планку памяти смысла нет. Если не знаешь, что надо делать — не делай ничего. Пусть исключение дальше летит.
Это неважно. Название просто от балды. Смыл в том, что обрабатывать надо только те ситуации, которые мы знаем, как обрабатывать.
Вот и отлично. Что поможет нам в результате разруливать разные ошибочные ситуации в будущем при саппорте, когда ошибки не будут маскироваться и зашумляться кодом, который не был спроектирован на обработку этих ошибок, но, тем не менее, зачем-то их обработал.