- 01
- 02
- 03
- 04
- 05
- 06
- 07
- 08
- 09
- 10
- 11
public class CollectionUtils {
public static function removeFromArray(_target_array:*, _element_for_deleting:*):void {
try {
var index:int = _target_array.lastIndexOf(_element_for_deleting);
if (index >= 0)
_target_array.splice(index, 1);
} catch (e:Error) {
RGB.entry.debug.throwError('CollectionUtils.removeElement() use only for Array or Vector');
}
}
}
Follow us!
http://www.joelonsoftware.com/items/2003/10/13.html
Функции низкого уровня типа readByte, readFloat кидают экцепшн если файл кончился или не читается, или же возвращают прочитанное значение. Если мы видем некорректные данные - тоже кидаем экцепшн. Вокруг всего этого стоит один трай-кетч, который ловит экцепшн, и превращает его в код возврата.
Вот здесь без экцепшена код превратится в сраное говнище, где чтение каждого поля обрамлено в if. А никаких бед в данном случае экцепшены не принесут, да и даже не провалятся за пределы функции загрузки, и не будут мешать тем, кто их не любит...
А когда логика программы перемешана с кучей проверок на ошибки (и не забыть проверить все случаи!), то это уже, может, и математически строже, но ни фига не понятней.
Ну и потом, иногда лучше подстраховаться, чем перестраховаться. Ошибка вероятна (неверный пользовательский ввод) - надо все проверить. Ошибка маловероятна (некорректные внутренние данные) - тратить время и место на проверку всего и вся не стоит. Тут достаточно сказать "извините, что-то не так, пошлите трейс разработчику". Или если ошибка в коде - тут все равно сделать ничего нельзя.
Если не ядро пишем и не программу для АЭС.
Я вот беру, и читаю:
{ do1; do2; do3; }
и я точно знаю, что если вы вошли в этот блок, то стопудов вызовется do3. Конечно, и на исключениях можно обрести уверенность, надо всего-навсего сделать так:
Меня тоже подбешивает писать try-catch для таких мест, но и без исключений еще хуже (в тех местах где они нужны).
Я точно не могу так взять, и сходу привести пример. Но случаи, когда я вижу код и понимаю, что если он выйдет в середине (в точке без явного выхода), то будет полная лажа - случатся достаточно часто. Если бы это было не так, то тогда бы не изобрели такую хитрую жопу, как транзакции, как раз на случай недовыполненности действия.
Тебе в хаскель. Там я слышал есть STM, хотя в лицо никогда его не видел.
Хорошо, тогда скажи, как правильно написать процедуру FreeAndNil?
Так?
или так?
Так вот, в траеблядстве таких траеблядских вопросов, в каком же блядь порядке выполнять какие-то там операции, дохуя, и траеблядские грабли подстерегают тебя на каждом шагу только потому что ты какую-то хрень сделал после другой хрени, а раии на всех не оберёшься, а вот стоит только постулировать, что такой-то код никогда не выкинет исключение, а если и выкинет, то только из-за грубой ошибки программиста, то сразу же всё упрощается в несколько раз.
Моя экспоненциально растущая лесенка, кстати, абсолютно корректна, если вы не поняли.
Кодовозвратобоги презирают ваши проблемы!
Сходи-ка на сосач. Тамошняя публика с радостью и пониманием воспримет твои ультразеленые идеи о ненужности эксепшонов.
Можно писать 90% без единого try~catch~finally. А исключения и обрабатывать ловить в самом верху.
Вот именно. Он никогда не писал их и говорит.
С одного счета клиента деньги сняли, но на другой не перевели из-за клинча, foreign key error, переполнения итд. А код Тараса пошел дальше, сделал всё что надо и в конце закомитился, в итоге клиент остался без денег и в страшном гневе бежит разбираться - как же так. Хе-хе.
Ну или писать ifы на каждый чих.
Может в геймдеве и полезно игнорить исключения - чтобы игра не падала по пустякам.
fixed
Я тебе еще раз объясняю, если ты работаешь с данными, то надо проверять каждый чих любой insert, update или вызов процедуры может не сработать.
А не будешь проверять - похерится целостность.
Так и try~catch не надо злоупотреблять. Многие просто не понимают где их надо ставить. И из-за паранойи лепят в каждой функции.
Мне такие вещи попадаются редко. А вообще у микрософта есть простой метод для таких вещей, в ядре используется.
> Так и try~catch не надо злоупотреблять. Многие просто не понимают где их надо ставить. И из-за паранойи лепят в каждой функции.
Более, того они ещё и кидают throw на каждый чих, в итоге вместо портянки ифов имеем портянку катчей, ну и нахрена это ради чего?
Ключевое слово мне.
Что-за метод?
Ага, а теперь взгляни на любую никсовую или виндовую апишку... Или кодовозвратобоги не опускаются до написания операционных систем, и, как хаскелисты, пишут исключительно абстрактный код в вакууме, который никак не взаимодействует с реальностью?
Ладно бы ты говорил о мире юникса. Я бы понял. Но тут ключевое слово _все_.
Но как раз та ОС, которую ты чаще всего юзаешь, и написана на исключениях.
Там ведь не сигналы, а именно SEH. MS даже свою сишку этим расширяла. Так что слив, гы-гы-гы.
И сколько же процентов кода в ядре игнорирует коды возврата других функций, и выглядит как do1; do2; do3? А сколько там функций, не возвращающих код ошибки?
P.S. У исключений по сравнению с кодом возврата есть большой плюс - на них сложно забить. Если ты не проверил код возврата, и что-то вдруг пошло не так - ты в полной жопе. Как ты будешь дебажить проблему, которая из-за этого вылезает у одного юзера из ста раз в месяц при невыясненных обстоятельствах, я не знаю. Читать гигабайты логов? Если же вылетело исключение, то в той же богомерзкой жабе у тебя будет стектрейс, который поможет тебе в разборе полётов.
Да я верю, что она корректна для определенной задачи. Но ведь эта задача и на ифах и кодах возврата будет смотреться не лучше ;) Если думаешь что лучше - приведи пример, как бы ты решил поставленную тобой выше задачу на кодах возврата. (Я так понимаю, что переход от линейной структуры из твоего коммента чуть выше к этой лестнице произошел из-за того, что нужна разная постобработка в зависимости от результатов операций?)
do1;do2;do3;
это если код изначально заточен на работу без исключений.
Нихрена подобного. Код Тараса забивает на возможные ошибки и продолжает исполнение. Не буду обсуждать плохо это или хорошо, видимо задача так требует. А данный код с траем может упасть на do1 и не выполнить do2 и do3. Полный аналог:
Код с самого начала пишется так, чтобы ничто никогда не кидало исключения. И библиотеки компилируются с соответствующими флагами.
Лол, траебляди настолько тупые, что ваще не вдупляют, как какая-то сторонняя функция может не кидать исключения)))
И игнорирует возвращаемое значение, говорящее об ошибке (если оно конечно есть)... Иначе бы тут стояли ифы, не правда ли?
А почему они игнорируются? Либо, в плохом случае, разраб ленивый пидорас, и ему похуй на то что прога будет молча творить хуйню, и при этом даже не падать. Либо, в хорошем случае, разраб умён и настолько уверен в том, что при исполнении этих функций не может произойти никаких проблем, что он объявил их как void, и не возвращает никаких кодов ошибок. Но в этом случае тот самый умный программист и в крестах может пометить функции do1() .. do3() как не бросающие исключений, и спокойно их вызывать.
> Лол, траебляди настолько тупые, что ваще не вдупляют, как какая-то сторонняя функция может не кидать исключения)))
throw() в описании крестофункции же.
Но ведь траеблядская проблема в том, что они и нормалньые функции переписывают в траеблядский стиль! И даже признак того, что мы дошли до конца массива у некотрых является исключением, и когда каждая вторая функция становится траеблядской, код становится писать намного сложнее.
В математической задаче полностью согласен. А в задачах, приближенных к реальному миру, как правило почти в каждой функции могут возникнуть проблемы - диск закончился, памяти нет, сектор сбойнул и байт прочитался не так, закрылся сокет, юзер умер за клавиатурой... И если на эти ошибки ложить хуй (они ведь очень редкие!), то программа вроде бы работает, но иногда молча сделает что-то не так... в лучшем случае недосчитает зарплату ее разрабу... А молчаливые ошибки - это самые страшные ошибки, никакой краш от пропущенного исключения не сравнится с ними.
Тарас просто давно не писал сишного системного кода, где каждый вызов может закончится фейлом. А надо последовательно занять пяток ресурсов, а если что-то не удалось, освободить в обратном порядке, а могут придти сигналы...
Ну вот, кстати, в OpenGL (с которым как-раз, наверное, работает Тарас) большинство функций написаны так, что они не могут возвращать ошибок. Почему? А потому что, емнип, любая команда OpenGL, которая захочет получить от драйвера какой-то ответ (glGet*, glGetError), будет ждать до тех пор, пока не выполнятся все команды, стоящие перед ней, а это убивает производительность вхлам. Поэтому об ошибке (вернее об ее почти бесполезном коде, без указания даже APIшки, которая ее вызвала) можно узнать только пост-фактум, в основном уже после конца кадра и свопа буферов...
Можно, конечно, для локализации бага сделать сборку игры, в которой после каждой команды будет стоять glGetError...
Видимо поэтому геймдевовцы, в том числе и Тарас, привычны к большим кускам кода, которые игнорят ошибки.
И как это влияет на код?
Если программы на том конце сокетов\пайпов написаны корректно, и адекватно реагируют на обрыв - все будет хорошо. Проблемы разве что с расшаренной памятью.
Несколько тредов захватили семафор, один из них подох. Что делать дальше - непонятно. Поэтому система поступает самым тупым и очевидным образом - не меняет при этом счетчик семафора, все равно ресурс, который был им защищен, уже распидорасило.
Причем виндовые вроде бы тоже. Для мутексов там запилили результат WAIT_ABANDONED, который возвращается треду, который ждал мутекса, а захвативший мутекс поток сдох без освобождения. Для семафоров же такого нет (или я не находил).
Плата за скорость семафоров + shm...
Можно, тут трабла не в реализации, а в том, что система должна сделать, если подох тред, держащий семофор. С мутексом все просто - уведомить его нового владельца о том, что ресурс распидорасило, и он попытается что-то восстановить. С семафором так не прокатит. У семафора нет определеного владельца. И один поток уже не сможет овладеть распидорашенным общим ресурсом и пофиксить его.
P.S. Поэтому не стоит убивать через kill -9 проги юзающие расшаренную память и семафоры... Остальные то сигналы они нормально обработают и все отпустят.
А в чем проблема. Таймаут спасет отца русской демократии (этакий вотчдог).
О как, покопался в мане по никсовым семафорам, нашел там флажок SEM_UNDO, который отменяет операцию над семафором при краше. Вот только логику, восстанавливающую ресурс, который защищал этот семафор, придется продумать самому.
"Довольно-таки плохо" (с)
Ядро сигналов не боятся, оно же их пересылает. А вот организовать надёжную работу и взаимодействие нескольких прецессов порой бывает сродни чёрной магии.
Сама сигнатура функции signal как бы намекает, что неопытным товарищам с ней лучше не связываться (ого что я нашёл http://govnokod.ru/1319)
И правильно делаешь. Пока программа справляется со своей работой путем мультиплексирования ввода-вывода или запуском независимых параллельных процессов - ну ее нахуй эту многопоточность..
Даже NotEnoughMemoryException?
Ты что, Тарасоаллокатор возвращает null, и он каждый раз проверяет результат на него. Какие еще исключения?
Пишешь на методе @Transactional или @TransactionManagement и немедленно наступает щастье без try-catch.
PS А еще есть АОП, которым можно абсолютно любую оборачивающую логику (а не только транзакции, автоrollbackи или игнор эксепшенов ) на все методы по регэксу, написав злополучный try всего лишь раз.
Но Тарас просто находится в ужасном плену ndk-крестоблядства и ничего этого не знает.
Сюда входит и тот случай когда каждый вызов оборачивается try-catch.
Вот зря ты это упомянул транзакции. Ты судя по всем не работал и потому не знаешь.
Вот возьмем близкий пример диалект sqlя без исключений, и как сторонник вендоплатформы и юзер студии, то думаю хотя бы чуть-чуть работал MS SQL.
В прошлых версиях там не было исключений. А часто бизнес-логика написана на хранимках.
Вот пример c исключениями, когда любая ошибка в любой из вложеных хранимок приводит к откату транзакции, то код выглядит так:
А вот что нам предлагает Тарас, чтобы обеспечить целостность данных при переводе
У меня вот процедура парсинга данных, введённых в форму вызывает парсинг каждой таблица, каждая таблица вызывает процедуру парсинга строк, те вызывают парсинг ячейки, короче вложение такое.
Ну и и меня код тупо такой:
if not ParseTable(Table1) then exit(false);
А, один лишь вопрос - куда записать информацию о том, где именно ошибка? Ну это не проблема, например, можно в возвращаемое значение.
У меня было брутально и бессердечно - программа не узнавала про то, где именно ошибка. Просто на самом нижнем уровне, если распарсить не удалось, то показывалось окно пользователю, типа чё за херь ты ввёл.
А как же паттерн отделения бизнес логики от интерфейса взаимодействия с пользователем?
Можно конечно, но тут ты смешаешь в одной структуре две сущности - собственно распарсенные данные и ошибку их обработки, тем самым намертво связав структуру и ее парсинг. А это не всегда айс (например если есть несколько разных источников, из которых получают данную структуру, и у каждого есть своя инфа об ошибках).
P.S. Но это все равно на порядки лучше, чем статический getLastError.
А передавать подробную информацию об ошибке вместе с исключением - это крестоблядская ересь, в нормальных языках кроме кода исключения хуй ты что передашь. А, ну в Аде какого-то хуя ещё есть костыль - вместе с кодом можно кинуть строку.
Ты это Хаскелю скажи:
Either Error' Float, так что Тарас модный посан и пользуется хаскельными методиками.
Это Тарас уже ниже написал Если не нравится, то передавай структуру {parserResult&, parserError&} смешивание будет только на верхнем уровне.. И это годный способ, т.к. ошибку можно будет отстегнуть.
А в том комменте он предлагал смешать поля с данными поля с ошибкой в одной структуре: Проще в ту структуру, в которую парсер пишет инфу, добавить поле для идентификации ошибки.
TParserData, TParserDataWithError : TParserData итд?
В boost полно нормальных либ. Мне вот unit_test очень понравилась.
Неужели то что успел понюхать лучше жабовского фреймворка?
Я правильно понимаю, что это толстый троллинг?
Мне жаба нравится как простой и понятный язык, но вот стандартная либа у нее, имхо, говно. И даже многие жабопрофессионалы тут со мной будут согласны.
Doug Lea. Особенно приложил руку ко второму.
На фоне остальной либы смотрится божественно.
Блох изначально разрабывал collections - тоже ниче, но местами говно кучукуется.
Кстати это в том числе строковой тред.
Добавлю String, StringBuiler(Buffer), CharSequence, Appendable - реально продуманные и удобные классы.
Буст большой. Тут скорее надо говорить про конкретные его куски, т.к. они всяко поддерживаются разными людьми.
да ладно
перепроверь в релизе -O2
шаблонная версия?
у нас crc16 бустом считается в релизе быстрее, чем раньше 15 лет считался табличным методом (с длинной таблицей, причем)
1. Написать макрос IGNORE_ERRORS( do1(); ) (С/С++)
2. Оформить do1/2/3 в виде комманд и использовать выполнятор комманд, ингорящий исключения (твой ООП язык здесь)
3. Написать функцию высшего порядка и использовать лямбды (твой функциональный язык тут)
4. Написать макрос, "отключающий" исключения как фичу языка (Lisp)
Для этого есть одна отличная фича, называется "деструкторы". К сожалению, не везде есть, вместо неё в жабосишарпах есть try/using, в Python - context manager, в Go - defer.
Сказать, чтобы от этого было легче, или, что проще понять что произошло врезультате ошибки, или что так легче программу написать - ой я бы сильно засомневался.
>except
>catch
>except
Ты где эту х*ню выкопал? Закапывай.
В реальной жизни ничего против исключений не имею, считаю Спольски упоротым троллем.
В ядре луникса есть еще одна причина - производительность.
>хотя ООП фишечки в ядре используются
Что именно? Передача указателя на функции? Таблицы этих самых функций?
Так это общепринятный подход. Его можно называть и функциональным и обзывать разными умными паттернами.
Лолчто? Ну разве что у них вся память пронумерована вверх-ногами.
Если первый "класс" имеет vtable, и все остальные расширяют этот "класс", тупо дописывая свои поля в конец, то смещение не нужно.
Собственно в с++ смещение при кастах возникает как раз в двух случаях - множественное наследование, и когда у предка нет виртуалок, а у потомка они есть.
Используй божественное RAII!
Можешь ещё глянуть на маленький Loki::ScopeGuard.h, но он правда не лямбда-подобный, в отличии от удобного фрагмента выше, работающего на любом крестокомпиляторе, где работает буст.
Ну и пользуйтесь умными указателями, COM-указателями и прочими враперами, пригодными для работы.
Трай кетч работает медленно это два.
И вообще мне этот метод с * не нравится.
Удаление из массива можно сделать в один заход, вместо двух, но не известно, будет ли быстее, зато некоторые нативные типы, тот же ByteArray тоже можно будет использовать с этой функцией.
Т.е.:
Таким образом избегаем повторного просматривания элементов до найденого, не полагаемся на indexOf(), которого нет у ByteArray. Ну и не создаем лишних сущностей с ошибками.
Эхх, я ведь статью для школьников писал, как это надо делать: http://forum.pascalnet.ru/index.php?showtopic=26642
Ёбаный в рот.
Прочитай мою статью для школоты ещё раз.
Понятно что статья для нубов.
А что если сделать структуру, суть которой - обертка для строк, которая содержит список ссылок на куски массивов с чарами (cow).
Ну то есть нам надо сделать replace('TarasBtarasBtaraS','B',' ').
Мы сохраняем ссылку на кусок исходной строки потом ссылку на пробел, итд.
В итоге новая строка будет содержать список массивов:
['Taras', ' ','taras',' ','taraS']
Профит - нет копирования памяти, быстрые инсерты.
Наша "виртуальная" строка может модифицироваться много раз, а когда будем выводить то обычно это выходной поток.
То есть копирование в принципе не надо.
Можно пример? Как-то пока не очень понятно как с этой структурой работать. Думаю на хаскеле это пару строк.
(1 ((2 3) 4) (((((5))))) 6)
распечатается как 123456. Ну и соответственно, добавить в конец такого дерева дешевле, чем если бы оно было обычным списком.
хотим добавить 7 в конец:
(list (1 ((2 3) 4) (((((5))))) 6) 7) -> ((1 ((2 3) 4) (((((5))))) 6) 7)
Картинка Roman.jpg:
А в других языках есть что-то похожее?
И вообще есть ли научное название для деревообразного связного списка, элементы которого - другие списки (которые в свою очередь либо примитивны - массивы [частный случай - 1 элемент] ), либо такие же композитные списки.
С виду похоже на Ropes
Мне в голову ничего лучше Zipperа не приходило.
А я грю об эффективных строках и списках.
Но в реальных приложениях строки обычно никто не насилует. Если только это не текстовый редактор.
Зато в среднем все операции (поиск по индексу, вставка, замена) совершаются за логарифмическое время или быстрее.
А конкатенация так и вообще - константно, не зависит от длины строки
>ссылку на пробел
То есть это 5 байт в место одного? Конечно же нет. В 64хбитной системе это 9 байт вместо одного?
Но я конечно признаюсь: Будет ещё и длина строки. То есть как минимум 10 байт в 64х системе на один символ. А когда операций пройдет много и строка превратится в гигабайты 10тибайтовых символов. Ну и все эти dereference очень дорогая операция, тк не кешфрендли.
Да.
>В 64хбитной системе это 9 байт вместо одного?
Да.
> Будет ещё и длина строки.
Обязательно. Хотя для чара можно сделать и отдельный класс.
Да. Со всем согласен.
>То есть как минимум 10 байт в 64х системе на один символ.
Нет.
Есть одна проблема - ты идиот.
Сохраняем ссылку на иммутабельный объект - строка.
Она создается 1 раз. 8 байт в 64-битной системе, 4 - в 32-х битной.
>А когда операций пройдет много и строка превратится в гигабайты 10тибайтовых символов
Выше я написал - мы всегда можем балансировать дерево.
Рекомендую для начала посчитать сколько будет стоит сделать много (пусть даже парочку) операций, на гигабайтовых строках обычным способом - через копирование массива.
В C# функция подобная этой вертает int, чтобы не генерировать исключения, тк функция низкоуровневая и боялись просадки производительности. (Уж и не знаю почему). Если ошибка, то она возвращает код, выходящий за диапазон байта.
http://govnokod.ru/12321
Используй обертку Maybe.
Я откажусь от своих слов, если мне предоставят доказательства того что Microsoft Excel написан без единого блока try~catch.
А он что, в одиночку писал ексель? Его не сдерживали контракты про то, что "эта функция может кинуть исключение, нельзя просто так продолжать писать код после неё"? А не после ли работы над екселем он сказал "да заебали!" и написал свою заметку?