Я ищу подходы к именованию исключительных ситуаций, хочу выработать более или менее строгую систему

Чтобы именование ошибок не было размазанным

Я ищу подходы к именованию исключительных ситуаций, хочу выработать более или менее строгую систему

Исключительные ситуации — исключительные. Внесистемные.

Это, конечно, логично. Но ещё логичнее было бы именовать эти внесистемные, неправильные ситуации.

Это, конечно, логично. Но ещё логичнее было бы именовать эти внесистемные, неправильные ситуации.

Может есть стандарт ? Standard of non-systemic incorrect situations. SNIS

Я ищу подходы к именованию исключительных ситуаций, хочу выработать более или менее строгую систему

Друг мой, как говорил мне мой научный руководитель, а он крайне уважаемый человек в сообществе, классификация чего бы то ни было - оно занятие крайне неблагодарное :D

Я к тому, чтобы использовать какой-то базовый набор слов при именовании исключений. Причем слова сами по себе должны быть кардинально простыми Все будет смотреться единообразно и красиво только если будут какие-то строгие правила...

По-моему сейчас будет спам

Этот чел подписался на все чаты

Нет, не будет. Я просто подписаля и все.

о том и речь. Только проблема в "стандарте именований", если можно так сказать

а точнее в его отсутствии

Ну так можно про любые классы сказать

Нет стандарта именования классов в программе

Нет стандарта именования классов в программе

а что такое coding style, м?

coding style устанавливается волюнтаристическим образом

а иногда и не устанавливается

@zamazan4ik а как ты именуешь кастомные исключения? (если нужно дать возможность их поймать и обработать по-особому в catch)

я в курсе как делать кастомные классы для исключений

ДА

ну тогда давай вот я примеры исключительных ситуаций приведу, а ты аргументируешь их именования?

Мой вопрос я не знаю отвечает ли он требованиям чатика. Допустим есть статический метод в A A newObject(){ return B; } A- абстрактный класс B наследует и реализует A. Как правильно вернуть объект B из функции A.

Почитать про указатели?

Что за тег для кода ?

Кто-нибудь может подбросить статей по именованию исключений? Ну или выдержку из coding style'ов? До сих пор в голове не выработалась строгая система именования исключительных ситуаций, а хороших, исперпывающих размышлений я так и не смог найти

https://google.github.io/styleguide/cppguide.html Naming -> Exceptions to Naming Rules

https://google.github.io/styleguide/cppguide.html Naming -> Exceptions to Naming Rules

ты бы хоть смотрел что кидаешь

/iqtest@FailsBot

ты бы хоть смотрел что кидаешь

ну я уж не говорю там перевести "Exceptions to Naming Rules" и понять что оно не имеет отношения к программным исключениям.

Есть два класса: Window и Context Context - это окружение, без которого нельзя работать с командами OpenGL Window - это окно, в которое можно рисовать что-либо (Context хранится внутри Window) 1)Передали в Window нулевые или отрицательные значения ширины/высоты (invalid_argument, допускаю) 2)ОС отказалась создавать окно (WindowCreationException? Но тогда почему мы отдельно вынесли invalid_argument?) 3)Неудача в создании контекста (либо бзик ОС, либо аппаратура не соответствует требованиям) 4)Недостаточно памяти для создания текстуры (на видеокарте)

Хотя опять же, если есть WindowCreationException и "ContextCreationException", то "ContextCreationException" заворачивается в WindowCreationException? А вот если мне надо понять, что произошел провал именно на этапе создания контекста?

да

у меня больше идеологические проблемы, скажем так

https://google.github.io/styleguide/cppguide.html Naming -> Exceptions to Naming Rules

спасибо, гляну

спасибо, гляну

так стоп, я этот кодинг стайл читал, там про именования исключений толком ничего не сказано

1) unsigned

Более того, написано "We do not use C++ exceptions."

2) какойнить system_error

1) unsigned

может быть нулем

2) какойнить system_error

тоже самое для контекста? Тогда как их различать-то?

может быть нулем

это ошибка? не думаю

тоже самое для контекста? Тогда как их различать-то?

отнаследуйтесь если вам надо, но зачем их различать?

это ошибка? не думаю

сильно зависит от ОС. Идеологически - ошибка

не настолько ошибка чтобы ее отдельно ифать

кидайте ошибку создания окна

отнаследуйтесь если вам надо, но зачем их различать?

Чтобы из-вне дать возможность разобраться в чем дело и пофиксить/дать более подробный вывод ошибки

Чтобы из-вне дать возможность разобраться в чем дело и пофиксить/дать более подробный вывод ошибки

для этого там есть сообщение внутри

но если получение детального сообщения ошибки - затратная операция, то что делать?

проброс исключения это уже значит что чтото пошло не так

и затратная операция будет не частой

в идеале никогда не вызываться

если у вас это поведение не выполняется значит вы делаете чтото не так

попахивает джаваспагетти немного

Мой вопрос я не знаю отвечает ли он требованиям чатика. Допустим есть статический метод в A A newObject(){ return B; } A- абстрактный класс B наследует и реализует A. Как правильно вернуть объект B из функции A.

~~~ A A::newObject(){ return B;} ~~~ A-абстрактный класс (static A newObject() ) B- класс который наследует A( class B::public A) Я не понимаю как правильно вернуть объект B из функции А. Если вариант наверху он говорит "нельзя испольвотать функцию возращающая абстрактный класс " Варианты, который я понял читая из инета это ~~~ A& A::newObject(){ return new B;} ~~~ Тогда придется делать delete( Еще один вопрос могу ли внутри класса сделать ~~~B B::del(){delete this;}~~~ ?). Как можно вернуть объект B?( я знаю вариант с умными указателями, но можно без них ).

~~~ A A::newObject(){ return B;} ~~~ A-абстрактный класс (static A newObject() ) B- класс который наследует A( class B::public A) Я не понимаю как правильно вернуть объект B из функции А. Если вариант наверху он говорит "нельзя испольвотать функцию возращающая абстрактный класс " Варианты, который я понял читая из инета это ~~~ A& A::newObject(){ return new B;} ~~~ Тогда придется делать delete( Еще один вопрос могу ли внутри класса сделать ~~~B B::del(){delete this;}~~~ ?). Как можно вернуть объект B?( я знаю вариант с умными указателями, но можно без них ).

возвращай std::unique_ptr<A>

Мм... Ну да, есть немного. Просто я многие вещи рассматириваю с точки зрения программирования графики Валидность переданных аргументов можно проверить самому (и довольно быстро!), но вот если ф-ция начинает работать неисправно - тут уже сложнее. Можно получить код ошибки, но чтобы получить описание ошибки - нужно выделить массив символов и повторно стучаться к OpenGL за подробным выводом. Я боюсь, что на каждую операцию пойдет дичайший оверхед Была и другая идея - через callback кешировать исключения в Context, но тогда будет сложно определить в каком же месте произошла исключительная ситуация. В рамках OpenGL, чтобы определить какая ф-ция и в какой строке дала сбой, надо каждый раз вызывать проверку наличия ошибки ._. Можно конечно дебагером попрыгать и выявить это место, но что делать если лог ошибок кидает пользователь программы? Сам факт наличия ошибки (не зная точного контекста возникновения) ни о чем не скажет, это аля мистика

(я про ф-ции OpenGL уже)

но это просто в качестве примера. Не знаю что делать

нет-нет, погоди

сейчас объясню

в рамках OpenGL есть два способа обработки ошибки: 1)после вызова ф-ции OpenGL вызвать ф-цию glGetError 2)внешним callback'ом просто вывести ошибку (но тогда теряется связь с кодом, неизвестно где именно она произошла) Если делать как в (1), то получаем дичайший оверхед, причем даже если ошибки как таковой и нет. Оверхед на каждую ф-цию OpenGL Если делать как в (2), то оверхеда как в (1) нет, но страдает информативность (неизвестно какая именно строка кода дала сбой)

в рамках OpenGL есть два способа обработки ошибки: 1)после вызова ф-ции OpenGL вызвать ф-цию glGetError 2)внешним callback'ом просто вывести ошибку (но тогда теряется связь с кодом, неизвестно где именно она произошла) Если делать как в (1), то получаем дичайший оверхед, причем даже если ошибки как таковой и нет. Оверхед на каждую ф-цию OpenGL Если делать как в (2), то оверхеда как в (1) нет, но страдает информативность (неизвестно какая именно строка кода дала сбой)

оверхед в каком плане? если вызов не прошел, вызвать glGetError(), собрать информацию об окружении и выбросить исключение. а если вызов прошел, то какой оверхед?

в 2к17 валидация только при дебаге юзается

она существенно замедляет

в 2к17 валидация только при дебаге юзается

огл сильно зависит от железа, на котором исполняется программа. На разных видеокартах от разных производителей поведение тоже может быть разным. Отключить полностью - самоубийство.

тем не менее

оверхед в каком плане? если вызов не прошел, вызвать glGetError(), собрать информацию об окружении и выбросить исключение. а если вызов прошел, то какой оверхед?

А как определить, что вызов не прошел? Только через glGetError, т.к. огл - это сишная библиотека

а в колбеке на обработку ошибки бектрейс почему не собрать?

а в колбеке на обработку ошибки бектрейс почему не собрать?

Можно подробнее?

а в колбеке на обработку ошибки бектрейс почему не собрать?

колбеке в 2017?

колбеке в 2017?

опенГЛ как бы

короче

мы все еще в этом контексте)) или он стал тру ООП?))

делай чем угодно

но делай отключаемым

опенГЛ как бы

ох уж этот легаси

ох уж этот легаси

на этом легаси сейчас все невиндовое работает :/

ох уж этот легаси

DirectX небось тоже труЪ ООП заделался?

ох уж этот легаси

ахах это же чат плюсов

DirectX небось тоже труЪ ООП заделался?

я бы сказал что vulkan для плюсов тру довольно таки

оберточка