Search Issue Tracker
Won't Fix
Won't Fix in 2022.2.X
Votes
0
Found in
2022.2.0a15
Issue ID
UUM-1562
Regression
No
Exceptions are not logged when thrown from "async Task"
How to reproduce:
1. Open project "LogsInAsync.zip"
2. In the Hierarchy window select "GameObject" GameObject
3. In the Inspector window press on three dots of the script Component and choose "Call Async Methods"
4. Observe the Console window
Expected result: Exception is logged
Actual result: Exception is not logged
Reproducible with: 2019.4.39f1, 2020.3.35f1, 2021.3.3f1, 2022.1.2f1, 2022.2.0a15
Reproducible on: macOS 11.6 (Intel)
Add comment
All about bugs
View bugs we have successfully reproduced, and vote for the bugs you want to see fixed most urgently.
Latest issues
- Crash on UndoManager::RegisterUndoInternal when applying added GameObjects to a Prefab
- [Asset Bundles] A new bundle hash is not generated when the name of a serialized field is changed
- Icon section shows incomplete message and unusable check box in Build Profiles and Player Settings window instead of “Not applicable for this platform” for Dedicated Server Platform
- Assets are created in the Package folders when creating assets via custom buttons in the Inspector window or other windows
- “Select” windows are named differently on Windows and macOS
Resolution Note:
This is normal C# behavior, by design:
- an async Task returning method will capture any exception raised within its body, so that that it can be handled by the consuming side (by awaiting within a try/catch bloc, calling task.Result, or task.Wait,...).
- so the exception is swallowed before the Unity runtime can see it as an unhandled exception, and as no other code awaits on the task object, it is somehow lost (ultimately, there will be an error happening when the Task objects gets garbage collected, but that won't produce a console entry).
The versions wrapped in an async void method don't have any way to capture and propagate to an awaiter, so those cases pass the exception to the runtime.
Resolution Note (2022.2.X):
This is normal C# behavior, by design:
- an async Task returning method will capture any exception raised within its body, so that that it can be handled by the consuming side (by awaiting within a try/catch bloc, calling task.Result, or task.Wait,...).
- so the exception is swallowed before the Unity runtime can see it as an unhandled exception, and as no other code awaits on the task object, it is somehow lost (ultimately, there will be an error happening when the Task objects gets garbage collected, but that won't produce a console entry).
The versions wrapped in an async void method don't have any way to capture and propagate to an awaiter, so those cases pass the exception to the runtime.