Size: a a a

2020 August 02

ПК

Побитый Кирпич... in supapro.cxx
Короче куча минусов
источник

ПК

Побитый Кирпич... in supapro.cxx
Вообщем с кодами возврата код превращается в гавно достаточно быстро
источник

ПК

Побитый Кирпич... in supapro.cxx
со всякими object.isValid() привет Qt
источник

NI

Nikita Ivanov in supapro.cxx
+++++++++++++++++++++++
источник

SS

Sergey Skvortsov in supapro.cxx
Побитый Кирпич
Потому что на кодах возврата ты не построишь контракты и гарантии. Тебе надо их вручную проверять. Они смешивают код и обработку ошибок. Ты не можешь проверить код возврата оператора или конструктора
Это проблема конкретно плюсов, что конструктор может только через исключения ошибки передавать
Много в прикладном коде на них контрактов и гарантий?
источник

SS

Sergey Skvortsov in supapro.cxx
Побитый Кирпич
со всякими object.isValid() привет Qt
Это опять же проблема существующих плюсов, а не подхода в целом, вон бумаги от tl:: помогают
источник

ПК

Побитый Кирпич... in supapro.cxx
Sergey Skvortsov
Валидируем на нагруженном бэке, GUI нет, весь сервис только формы проверяет
В high load имеет смысл делать разные оптимизации, в том числе и заменять в часто-фейлящихся кейсах исключения на чтот о другое
источник

ПК

Побитый Кирпич... in supapro.cxx
Sergey Skvortsov
Это проблема конкретно плюсов, что конструктор может только через исключения ошибки передавать
Много в прикладном коде на них контрактов и гарантий?
На конструктор накладывается фундаментальный контракт в С++ - создание валидного объекта
источник

ПК

Побитый Кирпич... in supapro.cxx
В прикладном коде это как раз обычно самый часто юзающийся контракт
источник

SS

Sergey Skvortsov in supapro.cxx
Побитый Кирпич
На конструктор накладывается фундаментальный контракт в С++ - создание валидного объекта
std::expected<T, E> совершенно так же задает валидный объект, если задает; в чем разница, кроме текущих ограничений плюсов?
источник

SS

Sergey Skvortsov in supapro.cxx
Да, конечно, сейчас на плюсах на expected больно писать по куче различных причин
источник

ПК

Побитый Кирпич... in supapro.cxx
Sergey Skvortsov
std::expected<T, E> совершенно так же задает валидный объект, если задает; в чем разница, кроме текущих ограничений плюсов?
Если возврат такой функции не надо проверять вручную, то такой подход лишён главного недостатка кодов возврата
источник

SS

Sergey Skvortsov in supapro.cxx
Побитый Кирпич
Если возврат такой функции не надо проверять вручную, то такой подход лишён главного недостатка кодов возврата
Ошибку в любом случае надо обработать, если мы про удобство разработки — то есть примеры синтаксического сахара как раз для безболезненного проброса ошибок выше
источник

SS

Sergey Skvortsov in supapro.cxx
Хотя это тоже субъективщина, вон кучу софта пишут на
if err != nil { return nil, err }
источник

ПК

Побитый Кирпич... in supapro.cxx
Короче:
void foo() {
 do_some1();
 send_data_to_db(data);
 // В этой строке у меня гарантия, что data успешно записаны в DB
 auto data2 = get_data_from_db(); // Тут я не должен проверять, что данные есть в DB, ведь есть гарантия, что они там.
 // data2 гарантированно валидный объект
}
Если такого нельзя добиться, то подход обработки ошибок гавно
источник

SS

Sergey Skvortsov in supapro.cxx
Чего такого?
источник

SS

Sergey Skvortsov in supapro.cxx
Побайтово равного синтаксиса?
источник

ЗВ

Захар Виноградов... in supapro.cxx
И получается если там больше методов, то нужно все вписывать в инсерт?
источник

ПК

Побитый Кирпич... in supapro.cxx
Sergey Skvortsov
Чего такого?
Нет, равного по гарантиям, без каких то дополнительных проверок
источник

SS

Sergey Skvortsov in supapro.cxx
Побитый Кирпич
Нет, равного по гарантиям, без каких то дополнительных проверок
std::expected<T, E> foo() {
  send_data_to_db()?;
  // В этой строке у меня гарантия, что data успешно записаны в DB
  ...
источник