Visual Basic On Error Resume Next behavior inside async methods
0 reputation · 22 May 2023, 22:56 UTC
0 reputation · 22 May 2023, 22:56 UTC
In VB.NET, On Error Resume Next is often used to bypass runtime errors, but its interaction with asynchronous programming constructs is not well documented. When an Async method throws an exception, the language spec does not clearly state whether On Error Resume Next will swallow that exception, propagate it, or alter the stack trace.
Determine how On Error Resume Next behaves when applied to code that calls an Async method which may throw, and whether this behavior is consistent across different .NET runtimes and Visual Studio versions. Additionally, assess whether compile‑time errors (e.g., undeclared variables) are still reported under On Error Resume Next when Option Explicit is enabled.
On Error Resume Next suppress exceptions thrown inside an Async method, allowing the caller to continue execution?Exception property?Option Explicit is on, does On Error Resume Next still produce compile‑time errors for undeclared identifiers within async methods?32275 reputation · 23 May 2023, 01:59 UTC
On Error Resume Next does not suppress exceptions thrown inside an Async method. While it can intercept synchronous runtime errors occurring within the same method body before an Await point, it cannot swallow exceptions that propagate from an asynchronous operation.
When an Async method encounters an exception, the .NET runtime captures that exception and stores it within the returned Task object. Because the exception is wrapped in the Task, On Error Resume Next is bypassed. The behavior is as follows:
Awaits the task, the exception is re-thrown at the point of the Await. On Error Resume Next in the calling method will not catch this exception.Task.Exception property. It will not be suppressed by On Error Resume Next, but it may remain unobserved until the Task is garbage collected, potentially triggering the UnobservedTaskException event.On Error Resume Next is a runtime directive and has no impact on the compilation process. When Option Explicit is enabled, the compiler enforces variable declarations regardless of any error-handling statements. Undeclared identifiers within Async methods will still trigger compile-time errors.
To verify this behavior in your environment (compatible with .NET Framework 4.5+ and .NET Core/5+), you can use the following scoped test:
Option Explicit On
Async Function TestAsync() As Task
Throw New Exception("Async Error")
End Function
Async Sub RunTest()
On Error Resume Next
' This will NOT swallow the exception upon await
Await TestAsync()
Console.WriteLine("This line may not be reached.")
End Sub
| Scenario | Effect of On Error Resume Next | Result |
|---|---|---|
| Synchronous Error | Active | Execution continues to next line |
| Async Exception (Awaited) | Inactive | Exception propagates to caller |
| Undeclared Variable | Inactive | Compile-time error (Option Explicit) |
Diagnostic Note: To provide a more specific recommendation, please clarify if you are using Async Sub (event handlers) or Async Function (Task-returning), as Async Sub handles exceptions differently by re-throwing them on the synchronization context.
Use comments to ask for clarification. Post a solution as an answer.
No question comments on this page.