🚀 Feature Request
Update: after discussion with Dmitry Gozman (@dgozman), we settled on just setting this.name in the constructor and not exporting the error to avoid expanding the export scope. This is sufficient for the primary motivation behind this change. Original proposed scope is below, for reference.
TargetClosedError is currently exported from the internal client/errors.ts module, but it is not part of Playwright’s public package API. Its constructor also does not set this.name, so instances created on the client have name === 'Error' rather than 'TargetClosedError'.
The proposed change is to:
- Export the class as
playwright.errors.TargetClosedError.
- Set
this.name = 'TargetClosedError' in its constructor.
I'd be happy to implement this change if it's approved.
Example
try {
await page.click('button');
} catch (error) {
if (error instanceof playwright.errors.TargetClosedError) {
// Handle a page, context, or browser being closed.
}
}Motivation
Consumers sometimes need to distinguish an expected target closure from other Playwright failures. Without a public class, consumers must inspect error messages, which is brittle, especially in this case, where the message can be overridden.
Playwright already exposes TimeoutError through playwright.errors.TimeoutError and sets this.name for TimeoutErrors. Exposing TargetClosedError through the same API would provide a stable and consistent way to identify this existing error category. Setting its name would also preserve the class identity in logs and serialized/deserialized errors.
My primary use here would be for less ambiguous error handling and reporting. I work on an application that uses Playwright to drive browsers for screenshot capturing, and we try to detect browser crash errors, like this TargetClosedError, vs. other types, but our only option for doing so is to compare against the string 'Target page, context or browser has been closed'. This feels brittle, since that string could change in different Playwright versions, or be overwritten by the error's constructor. Being able to compare against the error class would make this more robust. If increasing the export surface is a concern, setting this.name in the error's constructor would be almost as good without increasing the export surface.
🚀 Feature Request
Update: after discussion with Dmitry Gozman (@dgozman), we settled on just setting
this.namein the constructor and not exporting the error to avoid expanding the export scope. This is sufficient for the primary motivation behind this change. Original proposed scope is below, for reference.TargetClosedErroris currently exported from the internalclient/errors.tsmodule, but it is not part of Playwright’s public package API. Its constructor also does not setthis.name, so instances created on the client havename === 'Error'rather than'TargetClosedError'.The proposed change is to:
playwright.errors.TargetClosedError.this.name = 'TargetClosedError'in its constructor.I'd be happy to implement this change if it's approved.
Example
Motivation
Consumers sometimes need to distinguish an expected target closure from other Playwright failures. Without a public class, consumers must inspect error messages, which is brittle, especially in this case, where the message can be overridden.
Playwright already exposes
TimeoutErrorthroughplaywright.errors.TimeoutErrorand setsthis.nameforTimeoutErrors. ExposingTargetClosedErrorthrough the same API would provide a stable and consistent way to identify this existing error category. Setting itsnamewould also preserve the class identity in logs and serialized/deserialized errors.My primary use here would be for less ambiguous error handling and reporting. I work on an application that uses Playwright to drive browsers for screenshot capturing, and we try to detect browser crash errors, like this
TargetClosedError, vs. other types, but our only option for doing so is to compare against the string'Target page, context or browser has been closed'. This feels brittle, since that string could change in different Playwright versions, or be overwritten by the error's constructor. Being able to compare against the error class would make this more robust. If increasing the export surface is a concern, settingthis.namein the error's constructor would be almost as good without increasing the export surface.