Lighthouse: Use friendly error messages in "x is undefined" cases

[patrickhulce]

TypeError: Cannot read property '_timing' of undefined
  File "/usr/lib/node_modules/lighthouse/lighthouse-core/audits/time-to-first-byte.js", line 29, col 26, in Function.caclulateTTFB
    const timing = record._timing;
  File "/usr/lib/node_modules/lighthouse/lighthouse-core/audits/time-to-first-byte.js", line 47, col 33, in artifacts.requestNetworkRecords.then
    const ttfb = TTFBMetric.caclulateTTFB(finalUrlRequest);
  File "internal/process/next_tick.js", line 135, col 7, in process._tickDomainCallback

https://sentry.io/google-lighthouse/lighthouse/issues/407357986/

[wardpeet]

@patrickhulce what is the suggested fix here? (just want to know for future bug reports 😄 )

throw an exception when _timing isn't correct? (this will probably trigger getsentry as well XD)

if (!finalUrlRequest._timing) {
   throw new Error(our errror msg);
}

[patrickhulce]

Yeah basically the bug is on the error message, not the error existing. Not much we can do in that audit if we couldn't find the request :)

IMO we should try to minimize the debugStrings in the report that are of the form 'blah of undefined' and try to say what happened, like "Unable to identify the main resource" or something

[wardpeet]

Sorry that's what I was trying to say 😆 but we shouldn't throw an error just set the debugstring right?

[patrickhulce]

oh, no haha throwing an error seems fine! this is definitely not the expected case that we don't have timing information for the first request, good to have tracked in sentry

I was just flagging as a good candidate for friendlier message 😄

[brendankenny]

Well we have better network request fallbacks for timing info, so hopefully we have more intelligible error messages if anyone is still hitting this case :)