`@azure/search-documents` should export `RestError`

[jarpoole]

Is your feature request related to a problem? Please describe.

Typescript only allows assigning a type of unknown or any to the caught argument in a catch block. I would like to extract the statusCode property so I would like to narrow the type using err instanceof RestError.

Describe the solution you'd like
@azure/search-documents should export RestError

Describe alternatives you've considered
Currently I am importing from @azure/core-rest-pipeline but this is suboptimal because the instanceof does NOT work across versions of the same package so there is no guarantee that the version of @azure/core-rest-pipeline I am using will stay aligned with the version used in the SDK.

Additional context

Closest issue I could find was #24945 which is for a completely different service and package but conveys a similar message that exporting error types is important for error handling!

[timovv]

Putting the question of whether we should re-export RestError aside, core-rest-pipeline does expose an isRestError function which checks the error's name -- I would favor using this helper over relying on instanceof alone for the reasons you describe.

But back to the main question -- it seems we are inconsistent about re-exporting here, e.g. storage-blob does but keyvault-keys doesn't. I suspect most other packages don't. @xirzec -- any thoughts here, is this something we should consider doing generally?

[jarpoole]

@timovv wasn't aware of isRestError from @azure/core-rest-pipeline and you are right this is definitely preferable in this case!

Looking at the implementation it seems like there is logic to prevent mismatched package versions so I guess it will be safe to use so long as there isn't another exception from elsewhere called RestError ?

export function isRestError(e) {
    if (e instanceof RestError) {
        return true;
    }
    return isError(e) && e.name === "RestError";
}

Still very weird to depend on @azure/core-rest-pipeline given the expected use from the docs though

A generic approach that covers all packages in the SDK would be swell!

[xirzec]

But back to the main question -- it seems we are inconsistent about re-exporting here, e.g. storage-blob does but keyvault-keys doesn't. I suspect most other packages don't. @xirzec -- any thoughts here, is this something we should consider doing generally?

It seems reasonable to re-export the error types that a package might throw, we do something similar with credential types (e.g. AzureKeyCredential) to avoid the need to depend directly on core for these kinds of utilities. Perhaps isRestError is another good one to re-export.

/cc @jeremymeng @mpodwysocki