что вы такие дерзкие

Мы токсичные

Правильно. Он должен возвращать bool. А вот если ты хочешь уже РАСПАРСИТЬ И РЕЗУЛЬТАТ ПОЛУЧИТЬ -- должен кидать исключение

нет, он должен вернуть результат в виде Тип результата | Ошибка.

нет, он должен вернуть результат в виде Тип результата | Ошибка.

ДА кто же тебе это сказал?

Ну, кстати, для всего этого пилится же std::expected

Что очень годная штука, ящита.

нет, он должен вернуть результат в виде Тип результата | Ошибка.

Чё за GOStyle?

ящита*

ДА кто же тебе это сказал?

Опыт

Чё за GOStyle?

Это не Go. Это вполне себе Haskell, Rust и т.д.

Опыт

Мы уже говорили про твой опыт...

Чё за GOStyle?

теперь уже и го? Я говорю про нормальные плюсы без эксепшенов

теперь уже и го? Я говорю про нормальные плюсы без эксепшенов

Лол

Такого не бывает

Я вот у себя в плюсопроекте Either реализовал и успешно юзаю. Удобна.

Опыт

ОК, давай так. Расскажи, чем тебе мешает исключение в этом случае? Вот есть метод, он парсит JSON, возвращает значение типа BOOST::property_tree или как его там. Возвращает по значению. что ему возвращать в этом случае?

Я вот у себя в плюсопроекте Either реализовал и успешно юзаю. Удобна.

Это зависит от того как функция называется или что там у вас

ОК, давай так. Расскажи, чем тебе мешает исключение в этом случае? Вот есть метод, он парсит JSON, возвращает значение типа BOOST::property_tree или как его там. Возвращает по значению. что ему возвращать в этом случае?

Если у тебя JSON RPC на дофига запросов, то тяжёлые исключения это ну такое себе.

Это зависит от того как функция называется или что там у вас

А при чём тут название?)

ОК, давай так. Расскажи, чем тебе мешает исключение в этом случае? Вот есть метод, он парсит JSON, возвращает значение типа BOOST::property_tree или как его там. Возвращает по значению. что ему возвращать в этом случае?

Я хочу точно знать типы

Если она называется дай мне тип из джсона, возвращать ошибку такое себе

Без вот этого всего бреда с exception и ...

Я хочу точно знать типы

Тип возврата ты и так знаешь

Если она называется дай мне тип из джсона, возвращать ошибку такое себе

Должно быть два апи. С эксепшенами для тех, кому это критично и без них.

Должно быть два апи. С эксепшенами для тех, кому это критично и без них.

Да не бывает си++ без эксепшнов

Должно быть два апи. С эксепшенами для тех, кому это критично и без них.

std::expected

Должно быть два апи. С эксепшенами для тех, кому это критично и без них.

Ну ок, возми, напиши обёртку для этой библиотеки, или может форк, где сделаешь так.

Если бросаете эксепшены, то, будьт едобры, опишите их все.

Должно быть два апи. С эксепшенами для тех, кому это критично и без них.

Все программисты си++ по определению предполагают что все по умолчанию кидает эксепшн

Да не бывает си++ без эксепшнов

+

Ilia Zviagin (1) увеличил репутацию Aidar Fattakhov (2)

Если бросаете эксепшены, то, будьт едобры, опишите их все.

Да иди ты на Java программируй с таким стилем...

Если бросаете эксепшены, то, будьт едобры, опишите их все.

Ты можешь перестроить логику на другой тип гарантий? Не на бросит а на небросит?

Если бросаете эксепшены, то, будьт едобры, опишите их все.

Зачем тебе все типы исключений? Чтобы все поймать?

Да иди ты на Java программируй с таким стилем...

Ну не. Все исключения должны быть описаны

Это не дурацкая Java. тут можно сделать всё удобнее.

Да иди ты на Java программируй с таким стилем...

Может хватит говорить, что я должен делать?)

Писать catch(...) в корне процесса или потока это такое говнище, что каждый раз хочется бить по рукам.

Это не дурацкая Java. тут можно сделать всё удобнее.

Java не дурацкая

Ну не. Все исключения должны быть описаны

Кому они должны-то?

Java не дурацкая

Спалился

random_device - это обёртка над /dev/random или /dev/urandom или криптопровайдерами Windows Наксколько они удовлетворят вашим нуждам - решать вам.

как понимаю в современном Linux меня все устроит, спасибо

Java не дурацкая

Джава дурацкая

А ведь ещё если транзакциями обмазано, то пиздец

Кому они должны-то?

Пользователю кода.

Пользователю кода.

Ну, вот мне напр. это не надо.

random_device - это обёртка над /dev/random или /dev/urandom или криптопровайдерами Windows Наксколько они удовлетворят вашим нуждам - решать вам.

На кодфорцец не работает

Меня вот реально заебало каждый чих обмазывать try-catch и транзакциями на каждый сраный чих

Ну, вот мне напр. это не надо.

Ну вот и иди лесом)

Зачем тебе все типы исключений? Чтобы все поймать?

Да, безусловно. Я должен их обработать надлежащим способом, чтобы не положить сервис.

Меня вот реально заебало каждый чих обмазывать try-catch и транзакциями на каждый сраный чих

Так не надо каждый. надо в message loop прописать один стек, и всё. Или в какое-то аналогичное место

Меня вот реально заебало каждый чих обмазывать try-catch и транзакциями на каждый сраный чих

Для этого раии придумали кажется

Так не надо каждый. надо в message loop прописать один стек, и всё. Или в какое-то аналогичное место

Классное решенеи. И главное произвдительное.

Для этого раии придумали кажется

От обмазывания это слабо поможет

Да, безусловно. Я должен их обработать надлежащим способом, чтобы не положить сервис.

try { ///... } catch(...) { log.log("Opanyky!"); }

Хз, пишу по 2 катча в год

От обмазывания это слабо поможет

Ребята, в конце конов, всё просто. Все программисты делятся на две категории. Кто понимает исключения, и -- все остальные.

Хз, пишу по 2 катча в год

Я вот тоже...

Хз, пишу по 2 катча в год

Хотя, если очень сильно мешать C/C++ код, то да, наверное придётся фреймов try писать дофига

Ребята, в конце конов, всё просто. Все программисты делятся на две категории. Кто понимает исключения, и -- все остальные.

Да вы расист, батенька.

Для этого раии придумали кажется

Поэтому и появляются штуки типа Try, но это близко к ФП, который кому-то тут не нравится

Не, я просто ... не люблю

Да-да, ты расист.

Не, если серьёзно, то нет

Поэтому и появляются штуки типа Try, но это близко к ФП, который кому-то тут не нравится

как try c FP вообще? чисто императивная фигня...

Тут имеется в виду Try из Скалы, который почти-что Either

да

как try c FP вообще? чисто императивная фигня...

Ну и кроме всего прочего, в Haskell есть исключения...

aka std::expected, о котором нынче всякие Александрески рассказывают

Да, открывают Америку

Не. Исключения и Either — это всё таки разные механизмы.

И разные задачи решающие.

Одно другого не отменяет.

Это ведь старый холивор. Давайте про JSON забудем, и подумаем над сигнатурой простой функции int div(int a, int b); которая делит a на b. Исключение она должна бросить или errorcode вернуть в случае если b == 0.

Это ведь старый холивор. Давайте про JSON забудем, и подумаем над сигнатурой простой функции int div(int a, int b); которая делит a на b. Исключение она должна бросить или errorcode вернуть в случае если b == 0.

Должна бросить.

Исключение ))

Один умный дядька сказал, что если функция предполагает, что что-то может пойти не так, то она не должна кидать исключения. Исключения — это для совсем неожиданных вещей.

У него ошибка парсинга - исключительная ситуация

да, бесит, на андроиде кривые исключения

Это ведь старый холивор. Давайте про JSON забудем, и подумаем над сигнатурой простой функции int div(int a, int b); которая делит a на b. Исключение она должна бросить или errorcode вернуть в случае если b == 0.

+

Ilia Zviagin (1) увеличил репутацию Yuri Hudobin (1)

да, бесит, на андроиде кривые исключения

Что конкретно бесит?

Один умный дядька сказал, что если функция предполагает, что что-то может пойти не так, то она не должна кидать исключения. Исключения — это для совсем неожиданных вещей.

Александреску как-то сказал, что std::optional сделан ужасно, и что можно сделать лучше и красивее, только вот не сказал как.

Александреску как-то сказал, что std::optional сделан ужасно, и что можно сделать лучше и красивее, только вот не сказал как.

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

Это ведь старый холивор. Давайте про JSON забудем, и подумаем над сигнатурой простой функции int div(int a, int b); которая делит a на b. Исключение она должна бросить или errorcode вернуть в случае если b == 0.

Depends. Если контракт не предполагает, что может быть предан ноль — то это скорее всего exception, после которого нельзя восстановить программу. И вообще можно прерывать задачу с ошибкой. Если контракт функции предполагает любые значения, то можно как возвращать expected, так и кидать исключение.

Depends. Если контракт не предполагает, что может быть предан ноль — то это скорее всего exception, после которого нельзя восстановить программу. И вообще можно прерывать задачу с ошибкой. Если контракт функции предполагает любые значения, то можно как возвращать expected, так и кидать исключение.

Что там может предполагать какой контракт?

Что конкретно бесит?

без трай-кетча падает с unhandled exception, с ним - с сегфолтом ?

Что там может предполагать какой контракт?

Есть два типа интерфейсов, проверяющие пользовательский ввод и не проверяющие.

без трай-кетча падает с unhandled exception, с ним - с сегфолтом ?

Это какие-то неправильные пчёлы. И навреняка у них неправильный мёд.

Это какие-то неправильные пчёлы. И навреняка у них неправильный мёд.

да, в андроиде ебаное аби для исключений

Александреску как-то сказал, что std::optional сделан ужасно, и что можно сделать лучше и красивее, только вот не сказал как.

Зачем ему говорить, если естть D?

Есть два типа интерфейсов, проверяющие пользовательский ввод и не проверяющие.

Чё за бред? int a = 42, b = 0; int c = a / b; Где тут ввод?

a и b — это ввод.

Входные данные.

Где ты там ввод нашёл, ё?

Где ты там ввод нашёл, ё?

ну ты же напечатал

У тебя слово ввод это обязательное механическое действие по нажатию на кнопки?

Мы сейчас обсуждаем один маленький оператор! int c = a / b;

И что?

У него может быть разный интерфейс.

И всё.