Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Exception handling default for top-level statements #25607

Open
zahirtezcan opened this issue Aug 12, 2021 · 5 comments · May be fixed by #43694
Open

Exception handling default for top-level statements #25607

zahirtezcan opened this issue Aug 12, 2021 · 5 comments · May be fixed by #43694
Assignees
Labels
doc-enhancement Improve the current content [org][type][category] dotnet-csharp/svc fundamentals/subsvc in-pr This issue will be closed (fixed) by an active pull request. Pri1 High priority, do before Pri2 and Pri3 📌 seQUESTered Identifies that an issue has been imported into Quest.

Comments

@zahirtezcan
Copy link

zahirtezcan commented Aug 12, 2021

With .NET Core and also .NET 5 runtime, the default for stack-rewind on the main thread is, when the exception occurs the runtime does not rewind and your application crashes. Only thing you may get is an event trigger for uncaught exceptions from AppDomain.

What is the default exception handling for Top-level statements? Does it inject a try-catch block, so the stack unwinding occurs and we get our finally blocks working? Or, does it ignore everything about exception handling?


Document Details

Do not edit this section. It is required for docs.microsoft.com ➟ GitHub issue linking.


Associated WorkItem - 345704

@dotnet-bot dotnet-bot added the ⌚ Not Triaged Not triaged label Aug 12, 2021
@PRMerger14 PRMerger14 added fundamentals/subsvc dotnet-csharp/svc Pri1 High priority, do before Pri2 and Pri3 labels Aug 12, 2021
@svick
Copy link
Contributor

svick commented Aug 12, 2021

Top-level statements don't do anything special regarding exceptions. All they do is wrapping your code inside a class inside a method that is marked as the main method of the program.

Though I don't know anything about the behavior you're describing. As far as I can tell, finally blocks work just fine on the main thread in .Net Core.

@zahirtezcan-bugs
Copy link

zahirtezcan-bugs commented Aug 12, 2021

finally blocks run if stack-unwinding occurs. And, for runtime it is optional to implement stack unwinding in absence of root catch statement.

Here is my quick tests on different online compilers, one of them is .NET 5 other is dotnet v2:

https://dotnetfiddle.net/PQqZO6
https://replit.com/@zahirtezcanbugs/NoCatchFinally

EDIT: It can be beneficient to provide code here as well

using System;

public class Program
{
	public static void Main()
	{
		try
		{
			AppDomain.CurrentDomain.UnhandledException += (sender, e) => Console.WriteLine("UNCAUGHT " + (e.IsTerminating ? "TERMINATING" : ""));
			throw new Exception("GO");
		}
		//uncomment following line for finally to work
		//catch{}
		finally
		{
			Console.WriteLine("FINALLY");
		}
	}
}

@svick
Copy link
Contributor

svick commented Aug 12, 2021

Interesting, though I only see this behavior on Linux, not on Windows. And yes, it's the same with top-level statements.

This code:

using System;

try
{
    AppDomain.CurrentDomain.UnhandledException += (sender, e) => Console.WriteLine("UNCAUGHT " + (e.IsTerminating ? "TERMINATING" : ""));
    throw new Exception("GO");
}
finally
{
    Console.WriteLine("FINALLY");
}

Produces:

> dotnet run
UNCAUGHT TERMINATING
Unhandled exception. System.Exception: GO
   at <Program>$.<Main>$(String[] args) in C:\code\tmp\hwapp\Program.cs:line 6
FINALLY
> wsl dotnet run
UNCAUGHT TERMINATING
Unhandled exception. System.Exception: GO
   at $Program.$Main(String[] args) in /mnt/c/code/tmp/hwapp/Program.cs:line 6
>

@zahirtezcan-bugs
Copy link

This behaviour is default for the C++ compilers that I know of (MSVC, GCC, clang) unless you specify as a compiler flag. That is, for any thread I tend to put a root try-catch block to make RAII to work efficiently. Similarly, since unwinding and finally does not work, using statements do not work either.

So, interprocess communication or stateful service communication (some OS resources?) may not be shutdown gracefully and the documentation should reflect this accordingly.

@BillWagner BillWagner added the doc-enhancement Improve the current content [org][type][category] label Aug 13, 2021
@dotnet-bot dotnet-bot removed the ⌚ Not Triaged Not triaged label Aug 13, 2021
@BillWagner
Copy link
Member

Thanks for this discussion. As @svick points out, top level statements don't change the already defined behavior. That's worth stating in this article.

@BillWagner BillWagner self-assigned this Nov 22, 2024
@BillWagner BillWagner added the 🗺️ reQUEST Triggers an issue to be imported into Quest. label Nov 22, 2024
@dotnetrepoman dotnetrepoman bot added 🗺️ mapQUEST Only used as a way to mark an issue as updated for quest. RepoMan should instantly remove it. and removed 🗺️ mapQUEST Only used as a way to mark an issue as updated for quest. RepoMan should instantly remove it. labels Nov 22, 2024
@BillWagner BillWagner moved this from 🔖 Ready to 🏗 In progress in dotnet/docs November 2024 sprint Nov 22, 2024
@BillWagner BillWagner linked a pull request Nov 22, 2024 that will close this issue
@dotnet-policy-service dotnet-policy-service bot added the in-pr This issue will be closed (fixed) by an active pull request. label Nov 22, 2024
@dotnetrepoman dotnetrepoman bot added 🗺️ mapQUEST Only used as a way to mark an issue as updated for quest. RepoMan should instantly remove it. and removed 🗺️ mapQUEST Only used as a way to mark an issue as updated for quest. RepoMan should instantly remove it. labels Nov 22, 2024
@sequestor sequestor bot added 📌 seQUESTered Identifies that an issue has been imported into Quest. and removed 🗺️ reQUEST Triggers an issue to be imported into Quest. labels Nov 23, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
doc-enhancement Improve the current content [org][type][category] dotnet-csharp/svc fundamentals/subsvc in-pr This issue will be closed (fixed) by an active pull request. Pri1 High priority, do before Pri2 and Pri3 📌 seQUESTered Identifies that an issue has been imported into Quest.
Projects
Status: 👀 In review
Development

Successfully merging a pull request may close this issue.

6 participants