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

expose original error instead generic error #121

Open
shlomiassaf opened this issue May 30, 2018 · 1 comment
Open

expose original error instead generic error #121

shlomiassaf opened this issue May 30, 2018 · 1 comment

Comments

@shlomiassaf
Copy link

shlomiassaf commented May 30, 2018

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
Copy link

OndrejPiza commented Mar 29, 2019

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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants