-
Notifications
You must be signed in to change notification settings - Fork 16
Error Handling
ZjzMisaka edited this page Aug 26, 2025
·
8 revisions
If a work throws an exception and fails to execute, the thrown exception will be recorded. This information can be accessed in callbacks or in WorkEnded and ErrorOccurred event.
callbacks
powerPool.QueueWorkItem(() =>
{
throw new Exception("Message");
}, (res) =>
{
if (res.Status == Status.Failed)
{
Console.WriteLine(res.Exception.Message);
}
});WorkEnded event
Will be invoked after the work has been executed. The event parameters include the information of exception thrown during the execution of the work logic.
powerPool.WorkEnded += (s, e) =>
{
if (!e.Succeed)
{
Console.WriteLine(e.Exception.Message);
}
};ErrorOccurred event
Will be invoked after any exception is thrown in the work logic, callbacks, or events (except ErrorOccurred itself). The event parameters include the information of thrown exception.
Just as there is no "recycle bin for the recycle bin", users must catch exceptions thrown in ErrorOccurred themselves. Otherwise, the thread pool will crash.
powerPool.ErrorOccurred += (s, e) =>
{
if (e.ErrorFrom == ErrorFrom.Callback)
{
Console.WriteLine(e.Exception.Message);
}
};ErrorFrom
enum ErrorFrom
{
Callback,
DefaultCallback,
PoolStarted,
PoolIdled,
RunningWorkerCountChanged,
WorkStarted,
WorkEnded,
PoolTimedOut,
WorkTimedOut,
WorkStopped,
WorkCanceled,
WorkRejected,
WorkDiscarded,
WorkLogic,
}- Sync | Async
- Pool Control | Work Control
- Divide And Conquer
- Thread Pool Sizing
- Work Callback | Default Callback
- Rejection Policy
- Parallel Execution
- Work Priority | Thread Priority
- Error Handling
- Work Timeout | Cumulative Work Timeout
- Work Dependency
- Work Group
- Events
- Runtime Status
- Running Timer
- Queue Type (FIFO | LIFO | Custom | Deque)
- Load Balancing
- Low-Contention Design
Core
Results
Options