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
- Texture2D hash changes inside of an AssetBundle when rebuilding a SpriteAtlas bundle with an empty AssetPostprocessor Script enabled
- Aniso Level still applies when Generate MipMap is disabled in Texture Import Settings
- Mipmap Limit Groups long names are not truncated when creating a new Mipmap Limit Group with a long name
- “ArgumentException: Invalid double parameter.” error is thrown when Infinity is typed into the Fixed Timestep field
- GameObject becomes gray when using HDRP and STP together on 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.