EK
std::expected<T, E> foo() {
send_data_to_db()?;
// В этой строке у меня гарантия, что data успешно записаны в DB
...Что за синтаксис такой?
Size: a a a
2020 August 02
SS
Что за синтаксис такой?
Псевдокод из C++29
ПК
Псевдокод из C++29
Ну вот и получается, что пока исключения лучший из существующих вариант
O
std::expected<T, E> foo() {
send_data_to_db()?;
// В этой строке у меня гарантия, что data успешно записаны в DB
...Мне больше нравится такой вариант:
std::expected<T, E> foo() {
try send_data_to_db();
// В этой строке у меня гарантия, что data успешно записаны в DB
...SS
Ну это сахар
SS
Не важно в целом
EK
Нет, равного по гарантиям, без каких то дополнительных проверок
А в чём сложность добавить if после каждой операции?
Я понимаю, когда обращение к файлам и пр. «долгие операции», тут вопросов нет.
Я понимаю, когда обращение к файлам и пр. «долгие операции», тут вопросов нет.
SS
На самом деле и на го можно писать с
if err != nil { return nil, err }SS
Длинновато, конечно, но это не настолько критично в плане удобства разработки
ПК
А в чём сложность добавить if после каждой операции?
Я понимаю, когда обращение к файлам и пр. «долгие операции», тут вопросов нет.
Я понимаю, когда обращение к файлам и пр. «долгие операции», тут вопросов нет.
Если ты пишешь
if, то должен обработать случай, когда else. Что ты там писать будешь?EK
Если ты пишешь
if, то должен обработать случай, когда else. Что ты там писать будешь?Зачем?
Если if (!some()) return {}
Если if (!some()) return {}
ПК
Зачем?
Если if (!some()) return {}
Если if (!some()) return {}
Тогда гарантия успешной записи в БД у тебя будет только в else ветке этого if-а, а у меня гарантия есть всегда
O
Ну вот и получается, что пока исключения лучший из существующих вариант
И, тем не менее, при том, что он лучший из доступных, у него, видимо, есть фатальные недостатки, из-за которых им отказываются местами пользоваться. Я думаю, проблема обработки ошибок должна решаться расширением языка, а вариант заставлять всех использовать способ, который лично его устраивает больше — не очень, согласись
EK
Тогда гарантия успешной записи в БД у тебя будет только в else ветке этого if-а, а у меня гарантия есть всегда
Вместо else — продолжение кода.
ПК
И, тем не менее, при том, что он лучший из доступных, у него, видимо, есть фатальные недостатки, из-за которых им отказываются местами пользоваться. Я думаю, проблема обработки ошибок должна решаться расширением языка, а вариант заставлять всех использовать способ, который лично его устраивает больше — не очень, согласись
половина этих недостатков беспочвены (заблуждения), другая половина "исторически сложилась" типа гугла с их гавнокодом, который посыпется (просрёт все инварианты) если там выбросится исключение
ПК
Вместо else — продолжение кода.
Тогда получается что у тебя неправильная семантика функции. Она должна называться не
send_data_to_db, а try_send_data_to_db. И главное не забудь проверить, что данные успешно отправились :)LA
А есть какой-то generalized lambda capture для вариадиков?
Я где-то видел, даже сегодня, кажется, что-то вроде
Но он что-то не работает, ну или я налажал, когда с телефона пытался это написать...
Я где-то видел, даже сегодня, кажется, что-то вроде
[...xs = std::forward<decltype(xs)>(xs)](){}Но он что-то не работает, ну или я налажал, когда с телефона пытался это написать...
ПК
А есть какой-то generalized lambda capture для вариадиков?
Я где-то видел, даже сегодня, кажется, что-то вроде
Но он что-то не работает, ну или я налажал, когда с телефона пытался это написать...
Я где-то видел, даже сегодня, кажется, что-то вроде
[...xs = std::forward<decltype(xs)>(xs)](){}Но он что-то не работает, ну или я налажал, когда с телефона пытался это написать...
есть в С++20
LA
есть в С++20
Жаль. Именно такой синтаксис, да? А как называется?
ПК
Жаль. Именно такой синтаксис, да? А как называется?
не знаю как называется