SignalR HubException does not send innerException property

Describe the bug

HubException class has a constructor with innerException, but providing it does nothing, and client only sees message.

To Reproduce

Steps to reproduce the behavior:

1. Using this version of ASP.NET Core 2.2
2. It doesn’t matter whether EnableDetailedErrors option is true or false
3. C# Server: throw new HubException("I am error", new DivideByZeroException("infinitely"));
4. JS Client: Receives an error, which only has message and stack

Expected behavior

1. JS Client: Receives an error, which has message, stack, innerException.

Additional context

I’ve seen many discussions from code owners saying “We’ve considered customized objects before, but we only send messages now”, so maybe this is part of that decision. So is innerException just there as a noop, or can I send it somehow? Actually I want to send any custom object as an error.

message alone is not enough for me. Even though I own both server and client, I want to serve different cultures

For example,

1. JS Client 1: Does something bad.
2. C# Server: throw new MyException(123, ‘A’, ‘B’);
3. JS Client 1: Receives error -> Looks up error code 123 for Language 1 -> Tells user “‘A’ is not found in ‘B’”

But I also want to do,

1. JS Client 2: Does something equally bad.
2. C# Server: throw new MyException(123, ‘A’, ‘B’); // same as above
3. JS Client 2: Receives error -> Looks up error code 123 for Language 2 -> Tells user “‘B’ does not contain ‘A’… desu”

[BrennanConroy]

@Efreeto Just an FYI, that feature will not be in 3.0. It hasn’t been officially planned for a specific release yet.

[analogrelay]

Would it be truly exceptional circumstances if a server throws an error that a client using user should can know about and react?

Of course this is a design choice but in general the answer is no, this isn’t an exceptional condition. In general, if the caller is expected to be able to react and recover, an Exception shouldn’t be used. The .NET Best Practices for exceptions specifically try to avoid using Exceptions for cases the caller should be able to handle (https://docs.microsoft.com/en-us/dotnet/standard/exceptions/best-practices-for-exceptions#handle-common-conditions-without-throwing-exceptions).

We’re also looking at adding the “pipeline” concept described in that doc (https://github.com/aspnet/AspNetCore/issues/5353) which will help with error handling and management. You wouldn’t have to wrap every method in a try..catch for example, and would have some degree of customization over how the error is rendered.

We don’t plan to serialize the entire exception though, to be clear. We can’t do so in a way that guarantees the client will be able to deserialize it properly. While your application may be a tightly coupled .NET Server and .NET Client, this isn’t something SignalR can expect in general. Adding things like the Hub Pipeline will enable you more control over this when you do have a tightly coupled app, but SignalR shouldn’t be doing it in the general case.