Conditional catch for errors

^{Issue template didn’t really apply.}

I can’t find anything in the api docs page about error handling. The main type of error that’s encountered is a timeout. The issue is that there’s no documented way to distinguish the type of error received in the catch after awaiting a promise that rejects.

The issue is that good code (most of the time) needs to do conditional catches to avoid silencing unexpected errors. There doesn’t seem to be a good, stable way to do this currently.

I tried inspecting some of the errors. For these tests, the output is logging error and then logging {...error}.

await page.click('doesntexist');

// Result
{ AssertionError [ERR_ASSERTION]: No node found for selector: doesntexist
    at Console.assert (console.js:188:23)
    at Page.click (/private/tmp/temp-puppet-7695/node_modules/puppeteer/lib/Page.js:770:13)
    at <anonymous>
    at process._tickCallback (internal/process/next_tick.js:188:7)
  generatedMessage: false,
  name: 'AssertionError [ERR_ASSERTION]',
  code: 'ERR_ASSERTION',
  actual: false,
  expected: true,
  operator: '==' }
{ generatedMessage: false,
  name: 'AssertionError [ERR_ASSERTION]',
  code: 'ERR_ASSERTION',
  actual: false,
  expected: true,
  operator: '==' }

Gives a generic AssertionError with no information about the cause, except if you want to parse the error message, which seems very unstable as it can change without much notice.

The next issue is waitFor:

await page.waitFor('doesntexist');

// Result
Error: waiting failed: timeout 30000ms exceeded
    at Timeout.WaitTask._timeoutTimer.setTimeout (/private/tmp/temp-puppet-7695/node_modules/puppeteer/lib/FrameManager.js:593:58)
    at ontimeout (timers.js:475:11)
    at tryOnTimeout (timers.js:310:5)
    at Timer.listOnTimeout (timers.js:270:5)
{}

Again, the only way I see to extract information is the error message.

---

There are a few potential solutions here:

1. document the error messages and give an example regex to check them. This requires no code changes, but makes it clear that the error messages changing would be a breaking change.
2. don’t change the errors, but give official utility functions like puppeteer.isTimeoutError(error). Very little code changes, but the api will be stable across versions. Better than 1.
3. make each error either an Error subclass, or give it properties e.g. type: 'PuppeteerTimeout', selector: 'doesntexist'. This is about tied with 2, since it gives a readable way to check the error type.

Thoughts? Sorry if this has come up before, but I couldn’t find anything relevant.

[aslushnikov]

I currently regexp-match errors’ message property, and I’d sleep better at night if I had a trustworthy filter for puppeteer-originated errors.

@pwnall why puppeteer-specific error.code values aren’t good enough for your usecase? I prefer them to custom error classes for a few reasons:

• error.code values are lightweight
• error.code values fit nicer with the rest of the API: ATM we have no classes exposed, only instances.

[aslushnikov]

This sounds reasonable. How about using error.code for the purpose?

if (err.code === 'PPTR_TIMEOUT') {
  // .. handle timeout error
}