Client should not eat errors

[tsmaeder]

The language client handles a lot of errors and logs and eats then instead of propagating the errors to the VS Code API. For an example, see https://github.com/microsoft/vscode-languageserver-node/blob/master/client/src/client.ts#L1403

I believe this to be a wrong pattern: the errors need to be handled in the API anyway, because extensions not based on this here library may still produce errors, so we're doing the work twice. It also hides failures from the client. If we wanted to implement metrics, for example #failed completion item requests, failures from extensions based on this library would not be counted.

I think it would be better to propagate the failures through the API, for example returning a Thenable.

[dbaeumer]

The underlying reason why I implemented it that way is that the VS Code UI was not very nice when an provider failed (lots of notifications poping up). I am open to revisit this however we need to ensure that the user experience it nice as well.

[dbaeumer]

This got fixed in the meantime. The method that handles request errors now does:

	public handleFailedRequest<T>(type: MessageSignature, error: any, defaultValue: T): T {
		// If we get a request cancel or a content modified don't log anything.
		if (error instanceof ResponseError) {
			if (error.code === LSPErrorCodes.RequestCancelled) {
				throw this.makeCancelError();
			} else if (error.code === LSPErrorCodes.ContentModified) {
				return defaultValue;
			}
		}
		this.error(`Request ${type.method} failed.`, error);
		throw error;
	}