[JAVA-4641] Fix how InterruptedExceptions are handled Created: 10/Jun/22 Updated: 12/Sep/23 Resolved: 12/Sep/23 |
|
| Status: | Closed |
| Project: | Java Driver |
| Component/s: | Internal |
| Affects Version/s: | None |
| Fix Version/s: | 4.11.0 |
| Type: | Improvement | Priority: | Unknown |
| Reporter: | Valentin Kavalenka | Assignee: | Valentin Kavalenka |
| Resolution: | Done | Votes: | 0 |
| Labels: | loom | ||
| Remaining Estimate: | Not Specified | ||
| Time Spent: | Not Specified | ||
| Original Estimate: | Not Specified | ||
| Epic Link: | Virtual Threads Support |
| Quarter: | FY24Q3 |
| Backwards Compatibility: | Fully Compatible |
| Documentation Changes: | Not Needed |
| Documentation Changes Summary: | 1. What would you like to communicate to the user about this feature? |
| Description |
|
Before JEP 428: Structured Concurrency (Incubator), the importance of the interrupt mechanism for the driver was based mostly on the potentiality of user code to use the following pieces of the Java SE API: and on a few occasions when the driver uses this mechanism directly. Structured concurrency adds new functionality that relies on interrupts: "Any fork in a scope, their own transitive forks, or the scope's owner, can call StructuredTaskScope.shutdown at any time to signify that the task is complete, even while other forks are still running. shutdown causes the threads of all forks that are still active in the scope to be interrupted; all forks should, therefore, be written in a way that is responsive to interruption. In effect, shutdown is the concurrent analog of the break statement in sequential code.". This gives us one more reason to make sure the driver code is responsive to interruption. We discussed this with jeff.yemin@mongodb.com, and so far the agreement is that we need to make sure driver's code satisfies the following set of rules:
These rules mean, for example, that in situations when we catch Throwable/Exception in synchronous code and do not re-throw it as is, we must catch InterruptedException separately and then either throw it as is, or raise the flag. In asynchronous code, when we catch Throwable/Exception only to propagate it to a callback because exceptions in asynchronous code are not propagated through the call stack, we must not treat InterruptedException specially. |
| Comments |
| Comment by Githook User [ 12/Sep/23 ] |
|
Author: {'name': 'Valentin Kovalenko', 'email': 'valentin.kovalenko@mongodb.com', 'username': 'stIncMale'}Message: Fix how `InterruptedException`s are handled (#1192)
|