[tables] Add RestError export

[dhensby]

This adds the RestError class that can be thrown by the library to the exports so that consumers can more easily catch and perform instanceof checks on thrown errors.

This is the convention with @azure/storage-blob and @azure/storage-queue

[ghost]

Thank you for your contribution dhensby! We will review the pull request and get back to you soon.

[ghost]

All CLA requirements met.

[joheredi]

Thanks for your contribution @dhensby. I'd like to understand a bit more about the context and scope of this fix, is there any scenarios where you find we should be throwing a RestError but we are not? Or is this change just meant to export the RestError to be referenced, without any intended changes in the SDK behavior?

[dhensby]

Or is this change just meant to export the RestError to be referenced, without any intended changes in the SDK behavior?

That's absolutely right. It's so that the errors that are thrown can be caught and acted upon. For example:

const { TableServiceClient, RestError } = require('@azure/data-tables');

const client = new TableServiceClient(...);
client.createTable('mytable')
  .then(() => console.log('created table'))
  .catch((err) => {
    if (err intanceof RestError) {
      // some specific error handling
    }
  });

I have tried instead to import directly from the @azure/core-rest-pipeline library, but this is unreliable because of how npm can manage and de-dupe (or not) shared dependencies. So an approach like this that I have taken does not work in some instances:

const { TableServiceClient } = require('@azure/data-tables');
const { RestError } = require('@azure/core-rest-pipeline');

const client = new TableServiceClient(...);
client.createTable('mytable')
  .then(() => console.log('created table'))
  .catch((err) => {
    if (err intanceof RestError) { // this is fragile and will not work reliably
      // some specific error handling
    }
  });

This PR isn't intended to change any behavior, instead it just more clearly defines the contract between the package and the consumer.

[bterlson]

This point about importing error types from core being unreliable is good. We could probably have a guideline around always ensuring every error a package might throw has exported its type. This is also why I generally prefer people checking error name and code, but TS 4.4 made this a little more difficult in strict mode unfortunately.

[dhensby]

This is also why I generally prefer people checking error name and code

This is what I've done for the meantime, but as I posted originally, other @azure/* packages to export their respective RestError class, so it just felt natural this this library should too.

[xirzec]

Much like how we re-export credentials a SDK uses, I agree we should do the same for Error types.

[joheredi]

Thanks for the contribution @dhensby