- 主题:大家都用C++的try catch吗？
除了构造函数，还有运算符重载，总之异常系统在c++设计上难以避免。
类似的还有lambda表达式这种场景使得auto、decltype这些类型推断工具难以避免。
【 在 hongdiao 的大作中提到: 】
: 异常这玩意最早发明就是为了要处理构造函数发生的错误吧？ 构造函数这玩意压根没返回值， 不用异常用什么。 当然有些C++变种搞得奇奇怪怪的二阶段构造很丑陋就是了。。。
: --
: FROM 1.91.249.*
--
FROM 114.254.9.*
noexcept / unexpected/ expected
算不算呀？
【 在 z16166 的大作中提到: 】
: 哪里在纠偏？给出链接或者原文
:
--
FROM 47.96.236.*
大概算不上纠偏，不过c++在继续提供做来越多的选项。
c++23引入了expected类型以及一套Monadic工具，算是返回值方式处理错误的回归吧。这就是和类型，如果不往haskell之类函数式语言追溯，至少熟悉rust的话应该对Result不陌生。
【 在 z16166 的大作中提到: 】
: 哪里在纠偏？给出链接或者原文
:
: 【 在 overcomeunic 的大作中提到: 】
: ...................
--
FROM 114.254.9.*
到底是多“点”很关键
暂时不讨论偶发运行的程序块，影响不大。对于那些反复常态运行的，每次进入try都有开销，包含越大、代价容易越大，而且阻止内部优化，例如缓存啥的几乎全没了，对循环更是灾难，同样的代码编译出来肯定慢
【 在 z16166 的大作中提到: 】
: 不抛异常时，只有建立exception frame的那点开销吧
:
--
FROM 221.218.143.*
try catch，我觉得就是毫无意义的语法糖，跟编程语言的真正价值完全不搭边。
当初，某些做C++的人非要标新立异，非要弄得不一样。结果形式上改了，不用判断返回值了。结果，问题依然存在，依然需要处理，不仅如此，问题还变得更加复杂化了。
还不如老老实实判断返回值。C语言YYDS
--
FROM 114.254.0.*
异常挺好的
LoginException::ThrowOn(!$username, "用户名不存在",);
LoginException::ThrowOn(empty($password),"请输入密码");
不必写一大堆错误代码清晰么
【 在 hongdiao 的大作中提到: 】
: 异常这玩意最早发明就是为了要处理构造函数发生的错误吧？ 构造函数这玩意压根没返回值， 不用异常用什么。 当然有些C++变种搞得奇奇怪怪的二阶段构造很丑陋就是了。。。
--
FROM 223.198.83.*
异常本身就是小概率事件
【 在 overcomeunic 的大作中提到: 】
: 推荐个毛线
: 但凡持续抛异常，性能掉到底
--
FROM 223.198.83.*
异常不是标准的处理方式么？如果本级代码不知道怎么处理，直接抛出去让上级处理就行了，怎么会丢失调用栈呢？
--
FROM 115.183.88.*
不算吧
22楼说了。unexpected/expected算是在返回值处理这个flavor上试图做得更好
异常、返回值算是不同的flavor吧
翻到一个帖子，关于异常为啥用得没预期的多，该说的貌似他都说了
sandordargo dot com /blog/2022/11/16/cpp23-expected
【 在 overcomeunic 的大作中提到: 】
: noexcept / unexpected/ expected
: 算不算呀？
--
FROM 222.128.162.*
我拿异常做协程的通信方式，主要用于杀协程。
比如有个协程这么写:
try {
Timeout timeout(5.0);
// 下面一般接很多操作。而不简单一行。
return http->get(url, query);
} catch (TimeoutException &) {
qDebug() << "超时了！";
return QByteArray();
}
在以上代码，当协程执行到 http->get() 这个地方会阻塞住。因为事先注册了一个超时，所以 5 秒过后还没有返回结果，事件循环就会重新唤醒这个协程，但是抛出一个超时异常。
这个办法也被用于杀协程。比如用户点了取消按钮，我就会向所有正在运行的协程任务发送一个 CoroutineExitException 协程就会退出了。
【 在 wjhtingerx 的大作中提到: 】
: 这玩意儿把出问题的调用栈都弄没了，反倒不利于调试吧？
--
FROM 183.253.146.*