Socket.io error passing conventions

Question

Background: In Node, it is common to pass an error object to a callback function in async calls as well explained in Error handling in Node.js by Joyent. A standard error object contains a name, a message, a stack trace and possible additional properties. Passing or throwing strings or plain objects as errors is considered a bad practice. With Socket.io, data can be transmitted from client to server and vice versa by emitting events and having an optional response callback. This opens up multiple ways to pass and handle errors.

Question: If a socket.io event from a client causes an error on the server, what is the best practice to inform the client about this? A plain error object in response? A separate error event and listener? How the error should be structured? Is there any best practices like is the case with Node? What are you using?

Example: Imagine socket.io used for login. A client logs in by emitting a username and a password like below:

socket.emit('login', {user: 'Foo', pass: 'Bar'}, function (response) {
  ...
});

On a successful login, the response contains a session token. But what if the username or the password do not match? Several approaches come to mind:

Approach 1 - plain error object: The response could contain a property error having a plain error-like object as its value, with standard name and message properties and possible additional ones:

{
  error: {
    name: 'InvalidUsernameOrPasswordError',
    message: 'Username or password was invalid.',
    usernameExists: false
  }
}

The client thus tests if response contains an error and if not, continues with the login procedure:

socket.emit('login', {user: 'Foo', pass: 'Bar'}, function (response) {
  if (response.hasOwnProperty('error')) {
    // handle error
  }
  // do something with response.token
});

Approach 2 - simple string: Similar to Approach 1, but the error property is just a plain string representing the name of the error.

{
  error: 'InvalidUsernameOrPasswordError'
}

This approach is light and sufficient in this naïve example but lacks ability to pass additional data about the error.

Approach 3 - separate event: The server could emit and the client listen additional events to handle possible outcomes:

socket.on('loginError', function (error) {
  // handle error based on error.name and error.message
});
socket.on('loginSuccess', function (data) {
  // handle successful login with data.token
});
socket.emit('login', {user: 'Foo', pass: 'Bar'});

This approach feels the most explicit and pure under the event emitting paradigm but requires multiple event handlers.

Conclusions: There seem to be many possible ways to pass and handle errors. Any experiences, thoughts or feels?

Answer 1

It depends on your "clients". If you have end users like people using an application they really don't care so much about how you send the error. At the end you are going to have a text on the frontend saying they are wrong. So you are the one who have to select which way you prefer for implementing the error handling on the backend.

If your clients are not end users like the case above, imaging you are creating an application or library and you have to say there was an error. You should return as much as information you can in order for people who use your application identify where you error is.

So at the end:

-For customers: You will show your errors on the frontend so that ups to you how you want manage the error. -For developers: You should show as many error information as you can. Showing the stack trace, error code...