A common approach to the logging of error objects

[GeoffThorpeFT]

What problem does this feature solve?

I don't seem to be able to output the content of a thrown error. It. just appears as {}.

Ideal solution

Any instance of an error object in the logger output fields should trigger the log of all its properties.

Alternatives

Each author of each app could explicitly pick the properties of the error object they want to log. However, that implies they
know what the object will contain 😄

Example:

I have a postgres error. The two message lines below produce different output:

	try {
		await client.connect();
	} catch (err) {
		logger.error({
			event: 'GET_POSTGRES_CLIENT',
			err_message: err,
			stringify_message: JSON.stringify(err),
		});
		throw new Error(`Unable to contact ${process.env.DATABASE_URL}`);
	}

The first always shows {} whereas the second produces an errno,code, syscall, address and port.

[rowanmanning]

Thanks for opening this Geoff 🙂 and for popping over to chat about it. I'm gonna document what we discussed here for future reference.

As mentioned in the docs for the logger, errors are only serialized when they appear as a top level argument in a log method. This is partially for performance reasons and for backwards compatibility with n-logger.

We do also have the serialize-error package which safely extracts error information into a consistent format.

I think maybe a good middle ground is if we do serialize an error if it's present under a top-level err or error property. I think this will catch most of the places where people are currently doing this. I'm gonna open another feature request to document this specifically

[rowanmanning]

I've opened #480 to help address some of this