expose original error instead generic error

[shlomiassaf]

In the current implementation, starting a connection that fails will hide the original error thrown and expose a generic error that doesn't say much.

This can be seen here:

this._jConnection
  .start({ /* code ... */})
  .done(() => {/* code ... */})
  fail((error: any) => {
    console.log('Could not connect');
    reject('Failed to connect. Error: ' + error.message); // ex: Error during negotiation request.
  });

Also notice the console.log that is not guarded with "if (this._jConnection.logging)"
As you can see, the error is hidden from the end user, which will get a string excption that doesn't say much.

There is no reason for the library to hide the error object which holds valuable information about the reason the negotiation failed.

The error object is an instance of Error with 2 added properties: source and context which are identitcal (same object ref) and are jqXHR.

This object contains things like http resonse code status and statusText...

For example, in my server I need to provide a bearer token (OAuth2), if it's an invalid token I will get a 401 but with the current implementation i'm not able to identify this and act based on that.

I suggest we expose the entire error object as is, or even better expose HttpErrorResponse from @angular/common/http which is a perfect fit! an object which is an Error and an HttpResponse

export class HttpErrorResponse extends HttpResponseBase implements Error {
    readonly name: string;
    readonly message: string;
    readonly error: any | null;

    constructor(init: {
        error?: any;
        headers?: HttpHeaders;
        status?: number;
        statusText?: string;
        url?: string;
    });
}

[OndrejPiza]

Hi,

I vote for this issue and I would love to extend it to cover every error which is reported by SignalR. Right now I have to listen for specific code in case of error to do some other logic and in current state I have to simply find that code number in string, which is really not cool.

Sorry, that object is there, but it lacks signalR error interface, so I don't get hints.