Add error handling to expression runner

[flash1293]

This PR adds additional error handling capabilities to the expressions service of the data plugin.

It introduces a new option onRenderFailure which gets called if a render target element is passed in but the result of the expression can't be rendered because it isn't of type render or because the desired renderer is not registered.

There are two reasons for having such an API instead of just shifting this responsibility to the consumer who can inspect the result of the run themselves:

• It requires knowledge about expression internals (type, registries and stuff) which should not be necessary to run and render them. onRenderFailure is a more friendly semantic level for high level usage.
• It integrates nice with React which would make it difficult the get the result of the interpreter run

Another way of building this could be throwing exceptions if the rendering doesn't work. This could be used in React by adding an error boundary. However I feel that an error callback feels more consistent in our code base and makes it easier to ignore errors if you are not interested in them.

[elasticmachine]

Pinging @elastic/kibana-app-arch

[elasticmachine]

💚 Build Succeeded

• continuous-integration/kibana-ci/pull-request

[ppisljar]

seems we are mixing promises and callbacks ? to me it feels that if i have a promise, it will either resolve if everything goes fine or reject if it fails and i wouldn't be expecting i need to pass callbacks in. Also, what happens on error when i passed the callback in ? my promise will still resolve, so i will need to have special logic in my code (inside .then) to handle this correctly.

if i understand correctly main reason to go with this approach is to make it easier consumable from react ? we have the renderer react component which is supposed to do that, so probably we should make that one consume the rejected promises and the end consumer doesn't need to worry about this.

[flash1293]

Thanks @ppisljar, that's way better. I updated the PR.

On thing I'm uncertain about: Now the runner only rejects the promise if it also tries to render but this doesn't work, even when the result is an error. Calling the runner without an element to render to always resolves, even if the result of the interpreter run is of type: 'error'. Should the runner always reject in this case?

Or in other words should does this test https://github.com/elastic/kibana/pull/37968/files#diff-d1401db958bbe72cabce0674ffadc926R133 document the correct behavior?

[ppisljar]

yes, lets for now reject in that case.

[elasticmachine]

💚 Build Succeeded

• continuous-integration/kibana-ci/pull-request

[flash1293]

@ppisljar @lukeelmers Errors are now rejected even if the runner is not rendering

[flash1293]

Jenkins, test this.

[elasticmachine]

💚 Build Succeeded

• continuous-integration/kibana-ci/pull-request

[ppisljar]

code LGTM