Нашли или выдавили из себя код, который нельзя назвать нормальным, на который без улыбки не взглянешь? Не торопитесь его удалять или рефакторить, — запостите его на говнокод.ру, посмеёмся вместе!
+122
catch (TargetInvocationException ex) {
try {
throw ex.InnerException;
}
catch (EndpointNotFoundException innerEx) {
factory.Abort();
throw new InvalidOperationException("Service unreachable", innerEx);
}
}Обработчик исключений %)
Запостил: 
Guid,
16 Февраля 2011
Follow us!
вот за что я люблю простые целочисленные коды возвратов: заставляет народ думать что они пихают в коды ошибок.
нагородят сначала деревьев наследования эксепшенов, потом понагородят кучи catch блоков - кучи кода, логика размазана на сотни строк - хотя в реальной жизни веток обработки ошибок редко бошем 2-3 и все логика (если ее в одно место собрать) умещается на один экран.
да, получить ошибку "-28347812" это круто.
а за подробностями -- в глобальную функцию типа get_error_code()
если макаки не умеют юзать эксепшены -- это не значит, что они плохие
> если макаки не умеют юзать эксепшены -- это не значит, что они плохие
эксепшены не заставляют думать + эксепшены позволяют с легкостью создавать альтернативные code paths = говно, плохие.
Exception это с одной стороны внятное описание ошибки (по имени класса и сообщению) с другой стороны type-safe проверка.
Вы просто не умеете ими пользоваться.
если вы умудрились весь проект покрыть одним набором ошибок, то это значит что у вас проект мелкий. либо вы недостаточно ленивый что бы программированием професионально заниматся ;)
> Вы просто не умеете ими пользоваться.
да, да.
мне коллеги тоже расказывают что я не понимаю всех этих красот и прелестей. и я искренне надеюсь что никогда не пойму красот кода, обвешаного блоками `try { /* ... */ } catch(...) {}`.
блин теже goto и то меньше вреда читабельности кода наносят.
Вы, очевидно, не имеете отношения к энтерпрайзам, и наверное еще ООП презираете)
:) ах ирония. я работаю business support software (telecom), писаное на смеси С++ и жабы. более энтерпрайзней/масштабней/ООПей некуда.
может быть по этому и скучаю по простому читабельному коду.
Вот Вам юз-кейс.
Какой-то класс полез за файлом с важными данными. А файла-то и нет.
Он кинул DataFileNotFoundException("файл с важными данными не найден"), которое extends FileNotFoundException.
Если пользователь класса знает, что с этим делать -- он _может_ поймать его и что-то сделать (например попытатся найти файл и исправить его)
Если не знает -- эксепшен улетит дальше, где на самом верху его можно поймать уже как просто FileNotFoundException и показать пользователю красивое сообщение о ненайденном файле.
И наконец если его не поймает никто -- то приложение залогирует внятную ошибку с именем класса и сообщением, и админ приложения все поймет.
Теперь Ваше решение с цифровыми кодами возврата.
На мой взгляд исключение должно содержать в себе альтернативный вариант самообработки, и выдавать не сообщение администратору или кому-то ещё, а решение возникшей проблемы.
Вот здесь, решение с цифровым кодом - выглядит очень компактно. Мы получаем (номер, идентификатор) процедуры обработки данного типа исключения, обрабатываем его, и, (если это не fatal) продолжаем вести себя как ни в чём не бывало.
--
тоесть у нас есть где-то глобальная таблица обработчиков всех ошибок (как таблица векторов прерываний или обработчиков исключений в x86), да?
вот жеж красиво-то
бизнес-ошибки?
--
всё таки "показать пользователю красивое сообщение о ненайденном файле." и им подобные решения - не лучшие...
Эксепшен это ОБЪЕКТ который содержит:
1) код ошибки (класс) и потому его можно обработать програмно
2) информацию об ошибке (и потому ее поймет пользователь)
цифровой код не содержит второго пункта
и требует ЯВНОЙ передаче вверх по стеку
а Exception сам понему идет
класс это коробочка
у него есть контракт использования
там написано: "если я не могу сделать то, ради чего я создан -- я кину исключение"
что с ним делать решает тот, кто эту коробочку себе купил
--
"Когда писюльке хочется бабу, она кидает exception по иерархии наследования. Exception достигая на энном шаге своей реализации - пытается это реализовать, в случае fatal error - сигнализирует писюльке прекратить безобразничать, иначе - обеспечивает счастье писюльке"
--
Объект "писюлька" вообще не в курсе что происходит, если гормон иссяк - у неё есть спецкод для высшей инстанции.
Далее уже проблемы самой этой инстанции исключить исключение.
--
Но исключение, всё таки (в конце концов) исключается, либо откладывается. Программа (хвала создателю) не умирает, а продолжает работать, хоть как то.
нет. ГК для таких вещей не самое удобное место. но если настаиваете.
> Вот Вам юз-кейс.
то что ты описываешь это стратегия обработки ошибок. она не зависит от тактики обработок ошибок: исключения против кодов возврата.
про паттерн GetLastError()/etc писать не буду - или какой трейсинг (теми же аспектами) - уже тонны всего про это написаны.
class User -> class Document -> class File.
Юзер хочет сохранить файл и вызывает метод Сэйв у Документа. Документ например пытается загрузить темплейт Файл что бы потом юзверевы данные правильно отформатировать слить в Файл.
1. предположим что чтение темплейт Файла обламывается - Документ может попытатся обработать ошибку и слить темплейт с сети. как ты возвращаешь ошибку по барабану - Документ ее съел - Юзер ее не увидит.
2. предположим что чтение темплейт Файла обламывается - *но* Документу не нужно эту ошибку обрабатывать. теперь появляется разница. или?
2.1 коды возврата. Документ получает код ошибки от Файла. в интерфейс Документ эта ошибка не входит и Документу нужен свой собственный код ошибки - что бы сказать класу Юзер что произошла именно такая вот ошибка и он мог сам принять решение.
2.2 исключения. Юзер ловит исключение брошеное Файлом. иногда это ОК - но часто это плохо: Юзеру по уровням абстракции не нужно (а часто и нельзя) знать что Документ использует Файл. правильная обработка это Документу ловить *все* исключения и конвертировать их в нечто понятное пользователю, часть интерфейса Документ, на основании чего Юзер (как и Документ выше) тоже может предпринять какое-то осознаное действие по ошибке, а не просто плюнутся мессадж боксом. (юз-кейс: другая реализация интерфейса СетевойДокумент которая сохраняет данные не в Файл а например на СетевойСервер.)
2.3 на основании 2.1 и 2.2 в конце приходим к выводу что на стратегическом (высоком) уровне тактика обработки ошибок монопенисуальна.
>>паттерн GetLastError
это "паттерн" с одной функцией которая послднюю для треда ошибку возвращает?
прикольно наверное ее пересписать чужим вызовом.
паттерн "глобальная переменная", звучит.
2.1. тоесть Вам нравица по всему колстеку писать if (err == FILE_NOT_FOUND) {return DOCUMENT_FILE_NOT_FOUND;}
пзц
2.2 исключение МОЖНО поймать а можно не ловить. А еррор коды надо ВСЕГДА ЯВНО передавать выше.
2.3. фейл) Они могут наследоваца например. И непонятный MyInternalFileNotFound может быть пойман как обычный IOException и пользователь его увидит.
А если его поймают раньше -- то не увидит. полная свобода в отличии от кодов.
3.1.1 неизвестные исключения. в Файл добавили новых крутых фич и новых исключений. Документ никто не менял. но теперь загрузка темплейта может обломится с другим исключением, а Документ об этом даже и не узнает.
3.1.2 неизвестные коды ошибок. в Файл добавили новых крутых фич и новых кодов ошибок. Документ никто не менял. загрузка темплейта обломалась - Документ скорее всего ругнется что код то ошибки не правильный и просто скажет Юзеру что извини.
3.3 `catch(...)`. учитывая что народ народ плодит исключения, почти везде все приходится оборачивать в `catch(ProperException &ex) {}` *и* `catch(...) {}` - на всякий случай. (в C# по крайней мере догадались реализовать finally.)
3.4 `rc = CODE1 || rc == CODE2`. вот такая тривиальная конструкция не имеет аналога в исключениях: нельзя в один блок catch() словить два/более исключения. заканчивается как правило капипастом кода по catch() блокам.
вообщем, просто минусуй. я знаю что out-of-line error handling (ака исключения) народ не сильно варит в in-line error handling (ака коды ошибок) - в большей степени потому что в разных прикладных областях разные соглашения. корреная разница заключается в том что тот кто варит в in-line error handling, может переучится на out-of-line error handling - а вот наоборот это сложно. свойство исключений пронизывать уровни абстракций (которое ты как фичу сверху обозначил) слишком быстро растляет.
ЗЫ просто минусуй. не надо отвечать. мне спать идти рано надо сегодня. ауф видерзээн унд гутэ нахт.
ЗЗЫ ну вот. еще и разрезать ответ на пополам пришлось.
3.1.2 документ просто поймает исключение по умолчанию (FileException) и скажет что извини.
3.4 Это убогость конкретного языка. В питоне эту проблему решили например.
Там можно 10 исключений поймать. В жабе можно поймать ВСЕ исключения конкретного родителя.
>>свойство исключений пронизывать уровни абстракций
причем тут абстракции? Речь идет о колл-стеке.
Конкретные эксепшены видяца наверху как их родители.
>>вообщем, просто минусуй
да ладно, чего минусовать-то.
Я уже такого знаете сколько слышал? Исключения говно, ООП говно, статическая типизация говно.... Если человек не умеет чем-то пользоваться, то это говно.