异步调用时，异常rethrow的编程模式

Java异步异常处理
最新推荐文章于 2021-11-23 21:37:51 发布
最新推荐文章于 2021-11-23 21:37:51 发布 · 303 阅读 · 0
文章标签：

#编程 #多线程 #JVM #thread

本文探讨了Java编程中同步与异步场景下异常处理的最佳实践。重点介绍了在异步编程中，如何确保线程间异常的正确传递及记录，以方便问题定位与调试。

今天看到的一个问题，顺便总结如下：

 

Java编程中，程序异常处理是一个跑不掉的东西。

 

对于同步编程：

调用某个可能抛出checked或unchecked异常的方法时，可以直接在方法中声明throws继续往上处理，也可以在本方法中进行try catch处理(比如进行日志登记)。

catch处理后，是否进行throw e或throw new XxxException(e)视具体情况而定。这些处理，从技术上都是正确的，我们也处理地很好。问题不在这。

 

对于异步编程(重点)：

在线程A中，从底层的Thread.run一直运行调用到某个方法xxx()，xxx()设置线程之间的共享对象并notify通知另外一个线程B处理输入的任务，

如果任务失败时 (比如验证错误、程序空指针错误、超时错误等等)

这样情况下，通常按照以下判断程序的好坏：

1、 差的做法：A线程无法收到失败通知，也就是B线程产生的异常对象无法通知到A，使A无法接收该异常；

2、 好的做法：B的异常能够被A接收到！技术上是B发生异常时，要把异常记录到某共享对象，然后B线程通知A线程取回该异常。

 

但，xxx()获取到B的异常后，如何处理呢？分为3种情况：

1、 xxx() 自己try catch处理掉 — 没问题，如果真的应该由它处理的话

2、xxx() 需要把这个异常rethrow出去给上级调用者，
此时要注意了，请不要简单这样写throw exceptionFromThreadB; 而应该写成这样：throw new XxxException(exceptionFromThreadB);

3、 如果第1步的try catch中需要做logger.error记录，也请这样记录logger.error(“”, new XxxException(exceptionFromThreadB));，不写成logger.error(“”, exceptionFromThreadB);

 

为什么？

 

一个异常对象，意味着JVM dump出的当时的堆栈调用情况。throw 或rethrow出去的意味着，让上级了解当时这个堆栈。

如果只是throw/log.error exceptionFromThreadB，那么从后台的日志文件中，并不能看出原来是xxxx()这个方法进行异步调用发生的异常，更不知道是xxx()里面的具体哪一个步骤、哪一个代码调用的异步调用。

这会耽误程序的调试，问题的解决。

 

 

rethrow或log异常的同学多留意一下

ZhiliangWang
关注
14、Dart编程：异常处理、控制流与反射机制详解
3a9bq4r8t2y的博客
11-25 8
本文深入讲解了Dart编程语言中的核心特性，涵盖异常处理、控制流语句（如switch、assert、return、yield等）以及反射机制的使用方法与最佳实践。通过丰富的代码示例和流程图，帮助开发者理解Dart在错误处理、逻辑控制和运行时内省方面的独特设计，提升代码健壮性与可维护性。同时探讨了递归生成器性能优化、断言高级用法及动态对象操作等进阶主题。
基于C++11手撸前端Promise——从异步编程到现代C++实践
最新发布
2501_92808811的博客
09-20 720
一旦完成（成功或失败），状态不可逆地转变为 fulfilled 或 rejected，并依次执行对应队列中的回调。但鲜为人知的是，Promise 的核心思想（状态机 + 回调队列）完全可以用其他语言实现——例如用。注册回调后，主线程休眠 3 秒等待异步操作完成（实际项目中应使用更优雅的同步机制，如条件变量）。）手撸一个简化版 Promise，解析其关键概念与核心技巧，并通过详细代码分析展示实现逻辑。：这是核心逻辑的载体，封装了 Promise 的所有状态（实例，模拟一个耗时 2 秒的异步操作（通过。
多线程、异步调用异常场景测试
测试小小的博客
06-04 660
多线程、异步场景测试
关于Ajax连续异步调用失败的疑惑
Jo_El的专栏
11-09 1785
终于尝试用AjaxPro了，真的很好用，比起以前 自己构造XmlHttp方便多了。但是就在我用的不亦乐乎的时候，发现突然的某块功能不好使了。跟踪发现，在我的脚本里连续调用Ajax方法后，第二次就不管用了，连后台代码都没有跑进去。相关信息，我发布在Csdn论坛里求助了：http://community.csdn.net/Expert/topic/5141/5141454.xml?te
记录安全扫描后进行的代码重构各类问题以及处理办法
weixin_34126215的博客
09-19 6525
2019独角兽企业重金招聘Python工程师标准>>> ...
solrlin代码质量检查问题总结
遇见未知的自己
07-31 1万+
这两天在用SonarLint检测代码的时候，SonarLint检测出了很多问题。这里，记录一下。 1.Either log or rethrow this exception 修改方法： logger.error("queryStudentTeachClass方法执行错误",e); 处理异常时，需要进行两个操作： 1、使用context减缓复制的问题 2、保留原始异
Sonar常见问题解决方案
热门推荐
claireliu(Java)
08-30 5万+
阻断 1、Close this"FileInputStream" in a "finally" clause. 在finally中关闭FileInputStream，这个最为常见，主要是关闭方式不对，finally代码块中，应该要对每个stream进行单独关闭，而不能统一写在一个try-catch代码中，jdk 7 可以考虑try-resources方式关闭，代码相对优雅。   另外数据库
C++中的并发编程模式：多线程与异步编程实践大全
C++并发编程是现代软件开发中的核心议题，它包括多线程编程和异步编程模式等多个方面。本文深入探讨了C++并发编程的基础知识和高级特性，详细分析了多线程的创建、管理和数据共享问题，以及如何安全有效地使用互斥锁...
C++20 coroutine 探索III: 异步编程，Task＜T＞ 编写，boost asio 协程分析，C# async / await, cppcoro 源码分析
锐龙处理器
11-23 3232
经过了前面对 coroutine 的反复学习，现在尝试写一些封装好的协程工具（reinventing the wheel）。本文先从最Promise 异步编程模型的最基本的 Task<T> 入手. 异步编程 Futures and promises - Wikipedia 异步的关键点是真正的无线程异步必须要 all the way down 到 O/S system call 层面甚至到硬件层面的异步支持才能实现 (对于 Linux 的驱动模型, 做 top half 工作的 softirq
Boost.Asio与C++20协程融合实战：简化异步逻辑的6种现代编程范式
每当业务逻辑需要多步异步操作时，代码就像一棵不断分叉的树，最终变得难以维护、调试和测试。你是否也曾在某个深夜，对着一个五层深的回调链抓耳挠腮？ 直到C++20的到来，一切开始改变。 随着`co_await`这个神奇...
sonarqube检查出的bug修改总结
孙浩哥哥i的博客
10-19 1万+
1.修改异常处理      Either log or rethrow this exception.     private static String cc="error";     logger.error(cc,e); 2. 代码位置不符合规范  Move this variable to comply with Java Code Conventions.     放置到指定位置. ...
异常处理机制 --- 相知篇 （四）
理性的幻想
11-22 974
----------------------------------------------------------------------------------------------------------------------------- C++的异常对象按引用方式被传递          转自 http://se.csai.cn/ExpertEyes/No147.
[转]第14集 再探C++中异常的rethrow
candj的专栏
11-22 845
 From: http://se.csai.cn/ExpertEyes/200801031114531905.htm 第14集 再探C++中异常的rethrowhttp://www.csai.cn　作者：王胜祥　来源：希赛网　2008年1月3日　发表评论 -->　　　在相遇篇中的《第5集 C++的异常rethrow》文章中，已经比较详细讨论了异常重新被抛出的处理过程。但是有一点
异步调用方法时异常的捕获
weixin_34007291的博客
02-24 532
在异步调用一个方法时，由于不在一个线程内，异常的处理不同于普通同步调用，但可以在EndXXX时，使用try{}catch{}来捕获。 public static void main(string[] args){    string errorMessage = "this is error message";    Action&lt;int&gt; myWaiter = i =&gt;   ...
java api存在问题改进措施_Sonar常见问题解决方案
weixin_39956612的博客
03-06 2108
一、阻断1、Close this"FileInputStream" in a "finally" clause.在流使用完之后，应该关闭该流，finally代码块中，应该要对每个流进行单独关闭，而不能统一写在一个try-catch代码中。而且还要遵守一个原则：先打开的后关闭，后打开的先关闭。2、A"NullPointerException" could be thrown; "tom" is nu...
Java代码中常见技术债务处理之Exception
高效软件开发
04-06 1万+
写在前面异常处理是代码中常见的处理，本文根据SonarQube在异常方面的规则和常见检查结果，选取说明了常见异常处理中的技术债务，提倡技术债务最少的编码方式。Exception handlers should preserve the original exceptionsEither log or rethrow this exception. When handling a caught e
sonar常见错误以及处理方案
weixin_34032827的博客
05-19 2699
2019独角兽企业重金招聘Python工程师标准>>> ...
通过Sonar的代码质量报告学习【如何写安全高质量的代码】
AshenOne余烬
11-17 1万+
1.不要用.size()，改用isEmpty() Using Collection.size() to test for emptiness works, but using Collection.isEmpty() makes the code more readable and can be more performant. The time complexity of any is
packaged_task 使用异常场景
07-08
<think>我们正在讨论`std::packaged_task`的异常处理和使用场景。根据引用内容，我们可以总结如下： 1. **异常捕获**：通过`std::future`可以捕获任务执行过程中抛出的异常（引用[2]）。 2. **使用场景**：包括任务队列（如线程池）、异步编程等（引用[1]、[2]）。 现在，让我们深入探讨`std::packaged_task`的异常处理机制和相关使用场景。 --- ### 一、`std::packaged_task` 异常处理机制 当使用`std::packaged_task`封装任务时，如果任务执行过程中抛出异常，该异常会被捕获并存储到关联的`std::promise`中。随后，当通过`std::future::get()`获取结果时，异常会被重新抛出（在调用`get()`的上下文中）。 #### 1. 异常传递流程 ```cpp #include <iostream> #include <future> #include <stdexcept> int main() { // 封装一个可能抛出异常的任务 std::packaged_task<int()> task([]() -> int { throw std::runtime_error("任务执行失败"); return 42; }); std::future<int> fut = task.get_future(); // 执行任务（会抛出异常，但被packaged_task捕获） task(); // 异常被存储到promise中 try { int result = fut.get(); // 抛出存储的异常 } catch (const std::runtime_error& e) { std::cerr << "捕获异常: " << e.what() << std::endl; // 输出: 捕获异常: 任务执行失败 } return 0; } ``` #### 2. 关键特性 - **异常存储**：任务抛出的任何异常都会通过`std::promise::set_exception()`存储到共享状态中。 - **一次性抛出**：`future::get()`只能获取一次异常（与结果同理），之后`future`变为无效。 --- ### 二、异常处理的使用场景 #### 1. 线程池中的异常安全 在引用[1]和[2]提到的线程池场景中，`packaged_task`可确保工作线程的异常传递到主线程： ```cpp // 线程池任务队列示例 std::queue<std::packaged_task<void()>> tasks; std::mutex queue_mutex; // 工作线程 void worker_thread() { while (true) { std::packaged_task<void()> task; { std::lock_guard<std::mutex> lock(queue_mutex); if (tasks.empty()) continue; task = std::move(tasks.front()); tasks.pop(); } task(); // 执行任务（异常被捕获并存储） } } // 提交任务并获取future template<typename Func> std::future<void> submit_task(Func f) { std::packaged_task<void()> task(f); auto fut = task.get_future(); { std::lock_guard<std::mutex> lock(queue_mutex); tasks.push(std::move(task)); } return fut; } // 使用示例 auto future = submit_task([] { throw std::logic_error("计算错误"); }); try { future.get(); // 在主线程捕获异常 } catch (const std::exception& e) { // 处理异常 } ``` #### 2. 任务重试机制（引用[1]） 通过捕获异常，可实现自动重试： ```cpp void retry_task(std::packaged_task<int()>& task, int max_retries) { for (int i = 0; i < max_retries; ++i) { try { task(); // 执行任务 break; // 成功则退出 } catch (...) { if (i == max_retries - 1) { // 最后一次重试仍失败，存储异常 std::rethrow_exception(std::current_exception()); } } } } ``` #### 3. 异步调用链中的异常传递 结合`std::future`的链式处理： ```cpp std::future<int> async_chain() { std::packaged_task<int()> task1{[] { return 20; }}; auto fut1 = task1.get_future(); // 启动异步任务... // 下一阶段任务（依赖fut1的结果） std::packaged_task<int(int)> task2([](int val) { if (val < 0) throw std::domain_error("值无效"); return val * 2; }); return std::async([fut1 = std::move(fut1), task2 = std::move(task2)]() mutable { try { int input = fut1.get(); // 可能抛出异常 task2(input); return task2.get_future().get(); } catch (...) { // 处理或重新抛出 throw; } }); } ``` --- ### 三、注意事项 1. **任务重置与异常** 引用[2]提到`reset()`方法：仅当任务**未执行过**时才能重置。若任务已执行（无论成功或抛出异常），调用`reset()`会抛出`std::future_error`（错误码`no_state`）。 2. **共享状态生命周期** `packaged_task`析构时，若共享状态未被提取（即未调用`get_future()`）或未执行，其析构行为是安全的。但若已关联`future`且未执行，析构可能导致`future`变为无效状态。 3. **与`std::async`的对比** 引用[4]指出，`std::async`内部使用`packaged_task`，但自动处理了线程启动和异常传递。直接使用`packaged_task`更适合需要手动控制任务调度（如线程池）的场景。 --- ### 四、相关问题 1. 如何在`std::packaged_task`中捕获特定类型的异常并转换为错误码？ 2. `std::packaged_task`与`std::function`在异常处理上有何区别？ 3. 在多级任务链中，如何设计异常传播机制以避免丢失原始异常信息？ 4. 当任务在销毁前未执行，关联的`std::future`会处于什么状态？ 5. 如何结合`std::packaged_task`和`std::shared_future`实现多订阅者的异常广播？ > 引用来源： > `std::packaged_task` 的异常传递机制 [^3] > 线程池中的异常安全设计 [^1][^2] > 异步任务链的异常处理模式 [^4]</think>### `std::packaged_task` 异常处理机制与使用场景 #### 一、异常处理机制 1. **异常捕获与传递** `std::packaged_task` 会自动捕获任务执行中抛出的异常，并通过关联的 `std::future` 传递： ```cpp #include <future> #include <iostream> #include <stdexcept> int main() { // 封装可能抛出异常的任务 std::packaged_task<int()> task([] { throw std::runtime_error("Task failed!"); return 42; }); std::future<int> fut = task.get_future(); task(); // 执行任务（抛出异常） try { int result = fut.get(); // 此处重新抛出异常 } catch (const std::runtime_error& e) { std::cerr << "捕获异常: " << e.what() << std::endl; // 输出: 捕获异常: Task failed! } } ``` 2. **关键特性**： - **异常存储**：异常被存储到共享状态中，直到调用 `future::get()` 时抛出 - **一次性抛出**：与结果值相同，异常只能通过 `get()` 获取一次 - **状态一致性**：抛出异常后，`future` 状态变为 `ready`，`valid()` 返回 `false` #### 二、异常处理相关使用场景 1. **线程池中的错误处理** 在任务队列中捕获工作线程的异常（引用[1][2]）： ```cpp // 线程池任务提交函数 template<typename Func> std::future<void> ThreadPool::submit(Func f) { std::packaged_task<void()> task(f); auto fut = task.get_future(); { std::lock_guard<std::mutex> lock(queue_mutex); tasks.emplace(std::move(task)); // 加入任务队列 } return fut; // 返回future供调用方捕获异常 } // 使用示例 auto future = pool.submit([] { if (error_condition) throw std::logic_error("计算错误"); }); try { future.get(); // 主线程捕获异常 } catch (const std::exception& e) { // 处理异常 } ``` 2. **异步任务链的异常传递** 构建任务链时实现异常穿透： ```cpp auto task1 = std::packaged_task<int()>{ [] { throw std::overflow_error("第一阶段错误"); return 100; }}; auto fut1 = task1.get_future(); std::thread(std::move(task1)).detach(); // 第二阶段任务（依赖第一阶段结果） auto task2 = std::packaged_task<void()>{ [fut = std::move(fut1)] { try { int val = fut.get(); // 此处会抛出第一阶段的异常 } catch (...) { // 捕获并处理 // 记录日志或转换异常类型 throw std::runtime_error("任务链中断"); } }}; ``` 3. **任务重试机制**（引用[1]） 通过异常触发重试逻辑： ```cpp void retry_task(std::packaged_task<void()>& task, int max_retries) { for (int i = 0; i < max_retries; ++i) { try { task(); // 执行任务 return; // 成功则退出 } catch (...) { if (i == max_retries - 1) { // 最后一次重试仍失败，存储异常 std::rethrow_exception(std::current_exception()); } task.reset(); // 重置任务状态（引用[2]） } } } ``` #### 三、关键注意事项 1. **`reset()` 的异常限制**（引用[2]） - 仅当任务**未执行过**时才能调用 `reset()` - 若任务已抛出异常后调用 `reset()`，会抛出 `std::future_error`（错误码 `no_state`） 2. **异常类型保留** `future::get()` 会精确保留原始异常类型，包括自定义异常： ```cpp struct CustomError : std::exception { ... }; std::packaged_task<void()> task([] { throw CustomError(); }); try { task(); task.get_future().get(); } catch (const CustomError& e) { // 精确捕获 // 处理自定义异常 } ``` 3. **与 `std::async` 的对比**（引用[4]） `std::async` 内部使用 `packaged_task` 但自动处理异常传递，更适合简单场景： ```cpp // 等效于手动packaged_task的方案 auto fut = std::async([] { throw std::bad_alloc(); }); fut.get(); // 自动传递异常 ``` #### 四、最佳实践 1. **始终检查任务状态** ```cpp if (task.valid()) { try { task(); auto result = task.get_future().get(); } catch (...) { ... } } ``` 2. **异常安全包装器** ```cpp template<typename Func> auto safe_package(Func f) { std::packaged_task<std::invoke_result_t<Func>()> task([f] { try { return f(); } catch (...) { // 添加额外日志记录 throw; // 重新抛出 } }); return task; } ``` --- ### 相关问题 1. 如何通过 `std::packaged_task` 实现跨线程的异常堆栈追踪？ 2. `std::packaged_task` 与 `std::promise` 在异常处理上有何性能差异？ 3. 当任务在销毁前未执行，关联的 `std::future` 会抛出什么异常？ 4. 如何设计支持异常传播的异步任务链？ 5. 在分布式系统中如何通过 `std::packaged_task` 传递序列化异常？ > 引用来源： > `std::packaged_task` 的异常捕获机制 [^3] > 线程池中的异常安全实践 [^1][^2] > `std::async` 的异常封装实现 [^4]
评论
添加红包

请填写红包祝福语或标题

个

红包个数最小为10个

元

红包金额最低5元

当前余额3.43元 前往充值 >
需支付：10.00元
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付元
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明：

1.余额是钱包充值的虚拟货币，按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载，可以购买VIP、付费专栏及课程。

余额充值