core: centralize error strings #4280

patrickhulce · 2018-01-18T00:28:20Z

pulled the strings from the spreadsheet with some slight consistency modifications

vinamratasingal-zz · 2018-01-18T00:42:43Z

Maybe I missed this, but are we not adding in the error codes?

paulirish · 2018-01-18T01:23:54Z

lighthouse-core/test/gather/computed/first-interactive-test.js

@@ -28,7 +28,7 @@ describe('FirstInteractive computed artifact:', () => {
    return computedArtifacts.requestFirstInteractive({traceEvents: tooShortTrace}).then(() => {
      assert.ok(false, 'should have thrown for short trace');
    }).catch(err => {
-      assert.equal(err.message, 'trace not at least 5 seconds longer than FMP');
+      assert.ok(err.message, 'FMP_TOO_LATE_FOR_FCPUI');


i was expecting FMP_TOO_LATE_FOR_FCPUI to be the err.code, and the long string as the .message. What am i missing?

Maybe some wires got crossed. I expected the long string to just be used for display and not the one used in the stack/Sentry/CLI/etc. The codes are fairly self explanatory for us and the display string gets used in the report.

Error: FMP_TOO_LATE_FOR_FCPUI at repl:1:5 at ContextifyScript.Script.runInThisContext (vm.js:44:33) at REPLServer.defaultEval (repl.js:239:29) at bound (domain.js:301:14)

seems better in sentry than

Error: Your page took too long to load. Please follow the opportunities in the report to reduce your page load time, and then try re-running Lighthouse. at repl:1:5 at ContextifyScript.Script.runInThisContext (vm.js:44:33) at REPLServer.defaultEval (repl.js:239:29) at bound (domain.js:301:14)

Yeah that makes sense. Agree that the friendlyMessage is too wordy to be what we see in stack traces. Hmmm...
How about a basic LHError: ${err.code} ? Just prefixing the string with our custom error type.

Oh I like it,

LHError: FMP_TOO_LATE_FOR_FCPUI at repl:1:5 at ContextifyScript.Script.runInThisContext (vm.js:44:33) at REPLServer.defaultEval (repl.js:239:29) at bound (domain.js:301:14)

right?

or are you suggesting

Error: LHError: FMP_TOO_LATE_FOR_FCPUI at repl:1:5 at ContextifyScript.Script.runInThisContext (vm.js:44:33) at REPLServer.defaultEval (repl.js:239:29) at bound (domain.js:301:14)

1st one: LHError: FMP_TOO_LATE_FOR_FCPUI.
A la "TypeError" etc.

paulirish · 2018-01-18T01:25:16Z

lighthouse-core/runner.js

@@ -254,7 +254,8 @@ class Runner {

      Sentry.captureException(err, {tags: {audit: audit.meta.name}, level: 'error'});
      // Non-fatal error become error audit result.
-      return Audit.generateErrorAuditResult(audit, 'Audit error: ' + err.message);
+      const debugString = err.friendlyMessage || `Audit error: ${err.message}`;


I think we should add the err.code at the end of the debugString so we can differentiate the various errors with identical messages.

Alright, fine with me

patrickhulce · 2018-01-18T03:50:35Z

@vinamratasingal the codes are there, they are currently the way each audit accesses the error and the name that will show up in Sentry and (now after Paul's feedback) will be displayed in parens after the friendly message

vinamratasingal-zz · 2018-01-19T20:36:53Z

Cool, then SGTM from me. Once Paul LGTM'es I think we can #shipit

paulirish

Feedback!

I have a few questions around the gather-runner failed-to-load errors..

The rest of the feedback is fairly ordinary.

In addition to the notes below, we had CRI_TIMEOUT marked in our spreadsheet and that's omitted from this PR:

lighthouse/lighthouse-core/gather/connections/cri.js

Lines 118 to 120 in 2182513

    
           const err = new Error('Timeout waiting for initial Debugger Protocol connection.'); 
        
           err.code = 'CRI_TIMEOUT'; 
        
           log.error('CriConnection', err.message);

Aside from that, I've reviewed the spreadsheet and made sure it's all covered by this PR.

paulirish · 2018-01-19T20:10:09Z

lighthouse-core/test/gather/computed/first-interactive-test.js

@@ -28,7 +28,7 @@ describe('FirstInteractive computed artifact:', () => {
    return computedArtifacts.requestFirstInteractive({traceEvents: tooShortTrace}).then(() => {
      assert.ok(false, 'should have thrown for short trace');
    }).catch(err => {
-      assert.equal(err.message, 'trace not at least 5 seconds longer than FMP');
+      assert.ok(err.message, 'FMP_TOO_LATE_FOR_FCPUI');


Ah, separate note on this line.. seems like it should still be using equal() ;)

haha oops, done :)

paulirish · 2018-01-19T20:13:07Z

lighthouse-core/gather/gather-runner.js

+      log.error('GatherRunner', errorReason, url);
+      const msg = 'Your page failed to load. Verify that the URL is valid and re-run Lighthouse.';
+      const error = new Error(msg);
+      error.reason = errorReason;


where does this reason property go? can we just turn these two cases into two diff LHError codes?
back in the spreadsheet we agreed on two different codes for this. How about NO_DOC_REQUEST and FAILED_DOC_REQUEST ?

paulirish · 2018-01-19T20:13:31Z

lighthouse-core/gather/gather-runner.js

+    if (errorReason) {
+      log.error('GatherRunner', errorReason, url);
+      const msg = 'Your page failed to load. Verify that the URL is valid and re-run Lighthouse.';
+      const error = new Error(msg);


shouldn't this use an LHError?

paulirish · 2018-01-19T20:15:01Z

lighthouse-core/runner.js

@@ -254,7 +254,12 @@ class Runner {

      Sentry.captureException(err, {tags: {audit: audit.meta.name}, level: 'error'});
      // Non-fatal error become error audit result.
-      return Audit.generateErrorAuditResult(audit, 'Audit error: ' + err.message);
+      let debugString = `Audit error: ${err.message}`;
+      if (err.friendlyMessage) {


style nite: let's do a ternary for this const debugString assignment instead.

paulirish · 2018-01-19T20:15:46Z

lighthouse-core/gather/gather-runner.js

-      const error = new Error(`Unable to load page: ${errorMessage}`);
+    if (errorReason) {
+      log.error('GatherRunner', errorReason, url);
+      const msg = 'Your page failed to load. Verify that the URL is valid and re-run Lighthouse.';


Given the new text i think we need to change this guy now:

lighthouse/lighthouse-core/lib/sentry.js

Line 24 in 550b0c4

{pattern: /Unable to load/, rate: 0.1},

paulirish · 2018-01-19T20:28:05Z

lighthouse-core/lib/errors.js

+  constructor(errorDefinition) {
+    super(errorDefinition.code);
+    Error.captureStackTrace(this, LighthouseError);
+    this.friendlyMessage = errorDefinition.message;


And we can show your provided message in the CLI instead of

lighthouse/lighthouse-cli/run.js

Line 85 in b433a2a

console.error('Unable to load the page. Please verify the url you are trying to review.');

done, cleaned that area up a bit too

paulirish · 2018-01-19T20:33:08Z

lighthouse-core/lib/errors.js

+
+class LighthouseError extends Error {
+  constructor(errorDefinition) {
+    super(errorDefinition.code);


feels like we should also set this.code to be the code. that clean string should will persist all the way to CLI and devtools for those comparisons.

We'll have to update the error handling in devtools: https://github.com/ChromeDevTools/devtools-frontend/blob/28cf1d1a910a19f48c9a5d9d9374006f24179010/front_end/audits2/Audits2Panel.js#L708-L715 Can you make a note of that?

yeah sg, done

paulirish · 2018-01-19T20:38:14Z

lighthouse-core/lib/errors.js

+const errors = {
+  NO_SPEEDLINE_FRAMES: {message: strings.didntCollectScreenshots},
+  SPEEDINDEX_OF_ZERO: {message: strings.didntCollectScreenshots},
+  NO_SCREENSHOTS: {message: strings.didntCollectScreenshots},


just to note, this one isn't used yet. we created it for https://github.com/paulirish/speedline/blob/53b51d283fcbed69710eda58e8c3539f0fb9134d/src/frame.js#L105

do you want to catch the provided error and rethrow as LHError?

paulirish

lgtm, though i had one small suggestion.

nice stuff. :D

paulirish · 2018-01-31T02:52:19Z

lighthouse-core/lib/errors.js

+   * @return {!Error|LighthouseError}
+   */
+  static fromProtocolMessage(method, protocolError) {
+    const matchedErrorDefinition = protocolErrors.find(e => e.pattern.test(protocolError.message));


feels like doing this find() and iterating through the overall errors object (on L89) should be together.

this seems fine:

// extract all errors with a regex pattern to match against. findProtocolErrorDfn() then can find the matching one const protocolErrors = Object.keys(errors).filter(k => errors[k].pattern).map(k => errors[k]); const findProtocolErrorDfn = pattern => protocolErrors.find(e => e.pattern.test(protocolError.message)); ... const matchedErrorDefinition = findProtocolErrorDfn(protocolError.message);

sg, I also ~~errors~~ ERRORS to make it a bit more clear it's not just a local variable, wdyt? too ugly?

patrickhulce requested a review from vinamratasingal-zz January 18, 2018 00:29

devtools-bot added the waiting4reviewer label Jan 18, 2018

paulirish reviewed Jan 18, 2018

View reviewed changes

vinamratasingal-zz approved these changes Jan 19, 2018

View reviewed changes

paulirish requested changes Jan 19, 2018

View reviewed changes

patrickhulce added 4 commits January 19, 2018 14:08

core: centralize error strings

6f83cb5

nix .js

4a4d31b

add in the code

bfea8e6

feedback

fef29ac

patrickhulce force-pushed the ui_error_strings branch from 13b52ce to fef29ac Compare January 19, 2018 23:15

fix speedline rethrow

f251ef1

paulirish approved these changes Jan 31, 2018

View reviewed changes

clean up protocolErrors

564f15b

patrickhulce merged commit e8a1a7f into master Feb 1, 2018

patrickhulce deleted the ui_error_strings branch February 1, 2018 19:45

paulirish removed the waiting4reviewer label Mar 6, 2018

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

core: centralize error strings #4280

core: centralize error strings #4280

patrickhulce commented Jan 18, 2018 •

edited

Loading

vinamratasingal-zz commented Jan 18, 2018

paulirish Jan 18, 2018

patrickhulce Jan 18, 2018 •

edited

Loading

paulirish Jan 19, 2018

patrickhulce Jan 19, 2018

paulirish Jan 19, 2018

paulirish Jan 18, 2018

patrickhulce Jan 18, 2018

patrickhulce commented Jan 18, 2018

vinamratasingal-zz commented Jan 19, 2018

paulirish left a comment •

edited

Loading

paulirish Jan 19, 2018

patrickhulce Jan 19, 2018

paulirish Jan 19, 2018

patrickhulce Jan 19, 2018

paulirish Jan 19, 2018

patrickhulce Jan 19, 2018

paulirish Jan 19, 2018

patrickhulce Jan 19, 2018

paulirish Jan 19, 2018

patrickhulce Jan 19, 2018

paulirish Jan 19, 2018

patrickhulce Jan 19, 2018

paulirish Jan 19, 2018

patrickhulce Jan 19, 2018

paulirish Jan 19, 2018

patrickhulce Jan 19, 2018

paulirish left a comment

paulirish Jan 31, 2018

patrickhulce Feb 1, 2018

	const err = new Error('Timeout waiting for initial Debugger Protocol connection.');
	err.code = 'CRI_TIMEOUT';
	log.error('CriConnection', err.message);

core: centralize error strings #4280

core: centralize error strings #4280

Conversation

patrickhulce commented Jan 18, 2018 • edited Loading

vinamratasingal-zz commented Jan 18, 2018

Choose a reason for hiding this comment

patrickhulce Jan 18, 2018 • edited Loading

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

patrickhulce commented Jan 18, 2018

vinamratasingal-zz commented Jan 19, 2018

paulirish left a comment • edited Loading

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

paulirish left a comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

patrickhulce commented Jan 18, 2018 •

edited

Loading

patrickhulce Jan 18, 2018 •

edited

Loading

paulirish left a comment •

edited

Loading