Наши проекты:
Журнал · Discuz!ML · Wiki · DRKB · Помощь проекту |
||
ПРАВИЛА | FAQ | Помощь | Поиск | Участники | Календарь | Избранное | RSS |
[18.218.143.170] |
|
Страницы: (37) « Первая ... 27 28 [29] 30 31 ... 36 37 ( Перейти к последнему сообщению ) |
Сообщ.
#421
,
|
|
|
|
Сообщ.
#422
,
|
|
|
Какой еще мусорный код? О чем ты? Добавлено У тебя выходит такой же мусорный код будет везде где ты пишешь throw |
Сообщ.
#423
,
|
|
|
Цитата Wound @ Какой еще мусорный код? О чем ты? Про проверку кода и return. Для того, чтобы покинуть ошибку выше, придется это писать для каждого вызова. Для исключений тебе ничего не нужно делать. |
Сообщ.
#424
,
|
|
|
Цитата D_KEY @ Про проверку кода и return. Для того, чтобы покинуть ошибку выше, придется это писать для каждого вызова. Для исключений тебе ничего не нужно делать. Ну как это не придется придется, иначе потом тебе придется еще внедрять и SEH, ликбез про который выше выложил Qraizer. Ты как пишешь то? Вот как то так? void SomeMethod(SomePtr* ptr) { ptr->SOmeMethod(); } Добавлено Ну и плюс с кодами возврата - мне ведь нужно проверить код возврата. Т.е. я пишу if( someFunction(/*...*/) == err) return err; ... Мне ж в любом случае нужно убедится что не возникла ошибка. Просто я могу ее тут же обработать, а могу кинуть наверх, пусть с ней сами возятся. |
Сообщ.
#425
,
|
|
|
auto rc = f1(x, y, &r1); if (rc) { return rc; } rc = f2(a, b, &r2); if (rc) { return rc; } rc = f3(r1, r2, &r3); if (rc) { return rc; } vs auto r1 = f1(x, y); auto r2 = f2(a, b); auto r3 = f3(r1, r2); Или даже auto r = f3(f1(x, y), f2(a, b)); Добавлено Цитата Wound @ Ну как это не придется придется, иначе потом тебе придется еще внедрять и SEH Зачем? |
Сообщ.
#426
,
|
|
|
Цитата D_KEY @ Или даже Ровно тоже самое можно сделать с кодами ошибок. Вам же там в С++ уже и кортежи завезли и тьюплы разные, возвращать всякие структуры по идее должно быть просто. Как ты организуешь так и будет. |
Сообщ.
#427
,
|
|
|
Цитата Wound @ Ты как пишешь то? Вот как то так? void SomeMethod(SomePtr* ptr) { ptr->SOmeMethod(); } Что это? Не понял, какая связь с обсуждением. Но у меня тут будет или not_null<SomePtr*> или проверка на nullptr. |
Сообщ.
#428
,
|
|
|
Цитата D_KEY @ Зачем? Ну как зачем то. Потому что при отключенной настройке перехватывать системные исключения, очень много исключений(системных) твой catch не споймает. Например, как ты напишешь функцию, которая на вход принимает 2 числа, и возвращает результат от деления? |
Сообщ.
#429
,
|
|
|
Цитата Wound @ Цитата D_KEY @ Или даже Ровно тоже самое можно сделать с кодами ошибок. Покажи. С кодами возврата будет так, как я в начале написал. Добавлено Цитата Wound @ Потому что при отключенной настройке перехватывать системные исключения, очень много исключений(системных) твой catch не споймает. Ну значит я проверю сам и кину исключение(или еще как-то обработаю) |
Сообщ.
#430
,
|
|
|
Цитата D_KEY @ Что это? Не понял, какая связь с обсуждением. Но у меня тут будет или not_null<SomePtr*> или проверка на nullptr. Вот именно, проверка на nullptr - как раз и есть одно из "проверка кода возврата на ошибку". Т.е. ты не можешь написать так как выше, т.к. при нулевом указателе, ЕМНИП, обычный catch(...) ничего не споймает. В тех же явошарпах такие ошибки можно ловить, с помощью catch, а в С++ не прокатит такой трюк. AV не ловиться обычным механизмом исключений(если не выставить специальную настройку). И в итоге как ни крути ты хочешь не хочешь, а от кодов ошибки ты никуда не уходишь, хоть исключения и создают тебе такую иллюзию. Добавлено Цитата D_KEY @ Покажи. С кодами возврата будет так, как я в начале написал. Возвращать например структуру, которая содержит результат и код ошибки. Добавлено Цитата D_KEY @ Ну значит я проверю сам и кину исключение(или еще как-то обработаю) Так а чем это отличается от возврата ? Ровно те же яйца, только в профиль. Вот даже выше applegame про это и пишет. |
Сообщ.
#431
,
|
|
|
Цитата Wound @ Вот именно, проверка на nullptr - как раз и есть одно из "проверка кода возврата на ошибку" Нет, это проверка аргументов на соответствие предусловию. В случае not_null это уходит в систему типов и проверять отдельно ничего не нужно (в рантайме при попытке создать not_null из нулевого указателя будет исключение). |
Сообщ.
#432
,
|
|
|
Цитата D_KEY @ Нет, это проверка аргументов на соответствие предусловию. В случае not_null это уходит в систему типов и проверять отдельно ничего не нужно (в рантайме при попытке создать not_null из нулевого указателя будет исключение). Так это на сколько я понимаю, твой not_null - обычный враппер с проверкой на Null. То есть тот же мусорный код, только завернутый в обертку. По поводу проверки аргументов, не совсем. В данном случае - это был пример с аргументом, можно так же взять функцию, которая возвращает тебе указатель. Вот как раз это и есть код возврата. Если он нулевой - значит ошибка, если не нулевой, значит все впорядке. Например в WinAPI есть еще такая функция как getLastError. По сути вообще можешь забить болт на все коды ошибок, которые тебе возвращают функции. А вот там где надо, просто вызываешь getLastError и смотришь - если 0, значит никаких ошибок не было, а если не 0, значит какая то ошибка затесалась. Она тебе вернет код ошибки, дальше есть спец функция, которая тебе ее преобразует в читаемый текст. Ровно таже обертка. |
Сообщ.
#433
,
|
|
|
Цитата Wound @ Возвращать например структуру, которая содержит результат и код ошибки. Ты про Either(result<T, E>) и Maybe(option<T>)? Ну да, это уже вроде обсуждалось. Я за использование этого там, где "ошибка" - такой же валидный с точки зрения логики приложения результат. Например, при поиске чего-то в коллекции вполне логично возвращать option, чем кидать исключение. |
Сообщ.
#434
,
|
|
|
Цитата D_KEY @ Ты про Either(result<T, E>) и Maybe(option<T>)? Ну да, это уже вроде обсуждалось. Я это не юзал, но судя по вашему обсуждению - да, про это. Вся фишка в том, что можно написать и на исключениях трешак, ровно так же как и на кодах возврата. Но лично как по мне, понять/запомнить какие ошибки может вернуть функция, взглянув на ее сигнатуру - проще, чем сделать то же самое с исключениями. Но опять же все зависит от того, как ты все это напишешь. Например если функция возвращает ошибку как Enum, то тут уже просто через точку уже можно сделать вывод какие ошибки она в принципе может вернуть. А с исключениями как? Указывать спецификацию исключений, которые может генерить функция - как вариант, да, тут не спорю. Но ведь это нужно явно писать все руками. И везде замудохаешься это писать. Вот в чем проблема. |
Сообщ.
#435
,
|
|
|
Цитата Wound @ Так это на сколько я понимаю, твой not_null - обычный враппер с проверкой на Null. Ты не знаком с C++ Core Guidelines? Рекомендую. Про not_null: Declare a pointer that must not be null as not_null Есть библиотека для поддержки этого - gsl. Добавлено Цитата Wound @ То есть тот же мусорный код, только завернутый в обертку. Мусорным этот код становится от того, что его приходится писать на каждый вызов. Как я показал выше. И к чему относится картинка с особенной клавиатурой. В случае not_null мне не приходится писать такой код. И никакого мусора нет. |