-
Notifications
You must be signed in to change notification settings - Fork 80
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
Comments
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
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:
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 ofError
with 2 added properties:source
andcontext
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 anError
and anHttpResponse
The text was updated successfully, but these errors were encountered: