I ❤️ .NET

Table of Contents

1. What we gonna do?
2. Why we gonna do?
3. How we gonna do?
4. Summary

What we gonna do?

In this article, let's learn about Exception Handling and Logging in SignalR.

Note: If you have not done so already, I recommend you read the article on Message Pack Hub Protocol and Keep Alive in SignalR.

In our previous article, we learnt about what are Message Pack Hub Protocol and Keep Alive and how to configure them. Today in this article, lets learn about how to handle errors and log them in SignalR. We will also see how to log messages that are sent and received through the SignalR connection. This is useful for debugging and monitoring the communication between the client.

Why we gonna do?

When a hub method throws an exception, SignalR does not close the connection — it only notifies the client that something went wrong. Without understanding this behavior, developers often mishandle errors, either exposing sensitive stack traces to clients in production or silently swallowing errors without any meaningful feedback.

Proper logging is equally critical. Without the right log categories configured, it becomes nearly impossible to diagnose transport selection issues, hub method invocation failures, or connectivity problems in a running application.

Knowing when and how to use HubException, EnableDetailedErrors, and the correct logging categories helps you build secure, observable, and production-ready real-time applications with SignalR.

How we gonna do?

What happens when a hub method is invoked and an exception occurs? So when an exception occurs on the server, the connection will not close. The only thing the hub does is send a message to the client that something went wrong. The client library will detect that and throw the error.

// Hub
public class ILoveDotNetHub : Hub
{
    public override async Task OnConnectedAsync()
    {
        throw new Exception();
    }
}
            

And to see the exception message, there are two possible solutions. Instead of throwing a standard exception, you could throw a HubException. Now, the message is visible. This is usable when you deliberately want to send an exception message to the client, for example, a data validation error. SignalR will also throw HubExceptions itself when something goes wrong.

// Hub
public class ILoveDotNetHub : Hub
{
    public override async Task OnConnectedAsync()
    {
        throw new HubException();
    }
}
            

All exceptions that are not HubExceptions thrown on the server will not contain the exception message. But if you always want that message, no matter which exception is thrown, in Program.cs where SignalR is added to DI. Note that just the Exception message is sent to the client, not the stack trace or other exception information. You should be careful turning on EnableDetailedErrors because this information could also reveal possible attack vectors to your application. Therefore, I recommend not turning this on in production.

// Program.cs
..
builder.Services.AddSignalR(options =>
{
    options.EnableDetailedErrors = !builder.Environment.IsProduction();
});
..

var app = builder.Build();

..
app.MapHub<ILoveDotNetHub>("notifications");
..
            

To see more logs, Microsoft.AspNetCore.SignalR category is about all activity of hubs like invoking methods. You can also set Microsoft.AspNetCore.Http.Connections to get logging around transports such as which transport was selected and activity around the selected transport.

Summary

In this article, we learnt about Exception Handling and Logging in SignalR. We also saw how to handle exceptions as Hub Exceptions. In the next article, we will learn about Streaming and Authentication & Authorization in SignalR.