Printing error messages in CoreCLR

[kbaladurin]

Now when unhandled exception occurs coreclr prints information about it to stderr. It is suitable for console applications but not for applications with gui (for example mobile applications).

What is the best approach to print such messages also to syslog or other OS specific log in coreclr?

Thank you!

[kbaladurin]

cc @Dmitri-Botcharnikov @ayuckhulk

[kbaladurin]

@janvorli @jkotas PTAL

[jkotas]

Do you happen to know how other runtimes similar to CoreCLR deal with this problem on Unix? E.g. does Java log unhandled exceptions into a syslog?

The custom error handling seems to be app-model specific. For example, there was a recent discussion about how to handle unhandled exceptions when CoreCLR is hosted in IIS (https://github.com/dotnet/core-setup/issues/3447). It was worked around for now ... but the better solution would be to plug all unhandled exceptions into the IIS specific mechanism.

Would it make sense to add hosting API that the CoreCLR host can use to register their own custom unhandled exception handler? @kbaladurin Would it work for the Tizen GUI apps?

[jkotas]

Another approach is to register a custom unhandled exception handler during the UI stack initialization using AppDomain.CurrentDomain.UnhandledException.

[lemmaa]

For example, there was a recent discussion about how to handle unhandled exceptions when CoreCLR is hosted in IIS.

@jkotas, Could you point out where this was discussed?

And I agree with the first suggestion. During the Tizen commercialization experience with .NET, I feel that we need to extend the CoreCLR host API. The exception related API is also one of them. This will accommodate the problem beyond the AppDomain.CurrentDomain.UnhandledException can handle.

@kbaladurin, any thought?

[jkotas]

Updated link above (https://github.com/dotnet/core-setup/issues/3447).

[kbaladurin]

@jkotas Java doesn't log unhandled exception into syslog by default. User's code can setup unhandled exception handler using Thread.setDefaultUncaughtExceptionHandler method. If there isn't any custom handler it prints exception info to stderr (ThreadGroup class):

public void uncaughtException(Thread var1, Throwable var2) {
    if(this.parent != null) {
        this.parent.uncaughtException(var1, var2);
    } else {
        UncaughtExceptionHandler var3 = Thread.getDefaultUncaughtExceptionHandler();
        if(var3 != null) {
            var3.uncaughtException(var1, var2);
        } else if(!(var2 instanceof ThreadDeath)) {
            System.err.print("Exception in thread \"" + var1.getName() + "\" ");
            var2.printStackTrace(System.err);
        }
    }
}

In Android this approach is used to setup unhandled exception handler during zygote initialization before calling application's main (also it redirects stderr and stdout using System.setErr and System.setOut methods).

I think using similar approach in C# (AppDomain.CurrentDomain.UnhandledException) isn't appropriate for us because we use native launcher. Also registering unhandled exception handler during the UI stack initialization doesn't solve problem because exception can occur before it.

So I think extending CoreCLR host API is more appropriate for us if it make possibles to set unhandled exception handler from native code before calling application's Main method.

[ghost]

Due to lack of recent activity, this issue has been marked as a candidate for backlog cleanup. It will be closed if no further activity occurs within 14 more days. Any new comment (by anyone, not necessarily the author) will undo this process.

This process is part of our issue cleanup automation.

[ghost]

This issue will now be closed since it had been marked no-recent-activity but received no further activity in the past 14 days. It is still possible to reopen or comment on the issue, but please note that the issue will be locked if it remains inactive for another 30 days.

[ghost]

This issue will now be closed since it had been marked no-recent-activity but received no further activity in the past 14 days. It is still possible to reopen or comment on the issue, but please note that the issue will be locked if it remains inactive for another 30 days.