RestError prototype mismatches class name instead is Error

• Package Name: @azure/storage-blob
• Package Version: 12.11
• nodejs
  • version: v16.15.0
• typescript
  • version: v4.8.2

Describe the bug Facing issue with RestError imported from @azure/storage-blob.https://github.dev/Azure/azure-sdk-for-js/blob/80949a8a07f168c1e45188f52d9ddf09fffa8edc/sdk/core/core-http/src/restError.ts#L1

To Reproduce

console.error("Value of `e.name`", e.name);
console.error("Value of `e.__proto__`", e.__proto__);
console.error(
	"Value of `e instanceof RestError`",
	e instanceof RestError
);
console.error(
	"Value of `Object.getPrototypeOf(e)`",
	Object.getPrototypeOf(e)
);

[2022-08-26T06:16:53.310Z] Value of `e.name`: RestError
[2022-08-26T06:16:53.310Z] Value of `e.__proto__`: [Error]
[2022-08-26T06:16:53.311Z] Value of `e instanceof RestError`: false
[2022-08-26T06:16:53.311Z] Value of `Object.getPrototypeOf(e)`: [Error]

Expected behavior RestError event name to match its prototype.

[xirzec]

Going to close this for now as I don’t think there’s specific work we intend to do in core for this, but please re-open if I’m missing something!

[xirzec]

Turns out that WebPubSub uses the RestError from @azure/core-rest-pipeline. That is why the instanceof in our runtime is returning false, they are not the same RestError.

Ah yes, this is one of the issues that can arise. The other problem with instanceof is if you end up in a situation where you depend on different versions of the package that provides the error. We have a guideline related to this: https://azure.github.io/azure-sdk/typescript_implementation.html#ts-error-use-name

Because we are not totally heartless, we now provide a type guard you can use to avoid having to hand-roll your own detection logic: https://github.com/Azure/azure-sdk-for-js/blob/c4eeff48104c47035bc99d4fc4c118fd06b1d9e8/sdk/core/core-rest-pipeline/src/restError.ts#L93

In general, we plan to provide type guards for all custom errors to make life easier for consumers. Please let us know if you find some are missing.

Also, the fact that messages are coming through as empty strings should probably be fixed or investigated. Do let me know if you want me to open a separate issue for that: https://github.com/Azure/azure-sdk-for-js/blame/480e82cd0f9a8c40cd4ce66df978962661014c19/sdk/web-pubsub/web-pubsub/src/hubClient.ts#L513

Yes, please file an issue for this. I feel like the handling can be improved here. /cc @vicancy