Plan error handling about addons-linter

[muffinresearch]

I'm wondering if the sanest thing here would be to plan for an error object that is thrown with validation errors/warnings. Then we could catch them and display them at a single point in our app. Plus this would make handling each case differently quite straight-forward e.g. for web vs CLI.

[tofumatt]

I'm assuming this is all about validation errors (not coding errors 😄).

Agreed, a ValidationError object we use makes sense, but throwing an actual Exception/Error seems like the wrong idea. I'm of the mind that exceptions are for programming errors/unexpected inputs and a validation error isn't the same thing. Code that doesn't pass is expected (and probably common) input. I'd imagine instead any validator method would return (in its resolved Promise) an object with an array or warnings, errors, etc. Probably a simple passesValidation() method too so we can quickly check: is it valid (even if it had warnings but no errors)?

Without getting too deep into the API of a validate() method, I'd imagine it returns (a Promise) with a list of errors/warnings. eg:

validateFile(myFile).then(function(results) {
  if (results.passesValidation()) {
    console.log(results.errors);
    // null
    console.log(results.warnings);
    // [ValidationWarning]
    console.log(results.warnings[0].message, results.warnings[0].lineNumber);
    // "You didn't use a semicolon.", 72
    alert("Your add-on is the bee's knees.");
  } else {
    // Add-on validation failed.
    console.log(results.errors);
    // [ValidationError, ValidationError];
    console.log(results.warnings);
    // [ValidationWarning];
  }
});

[muffinresearch]

Yeah, good point - so the additional consideration is that we don't want to necessarily blow-up on the first issue we come across we need to collect up errors/warnings and display them at the end.

So we have a couple of distinct classes to think about:

App Errors:

• Programming errors (unexpected issues)
• App errors e.g. fatal errors from running the code (e.g. a zip can't be unpacked at all).

Validation output:

• Validation warnings.
• Validation errors.

The first being more likely to be exception based - the latter something like a list of objects that we can process at the end. Albeit in some case we might not complete the entire validation run because of an earlier error.

[tofumatt]

Definitely. The first set being exceptions sounds right to me too; we can't continue on a zip file error, which feels more like an exceptional.

The error and warning classes can probably extend a base "ValidatorMessage" or whatever. Only real difference would be that warnings are okay but errors mean an instant fail for validation.

• tofumatt (Sent from mobile)

On 28 Sep 2015, 15:53 +0100, Stuart [email protected], wrote:

Yeah, good point - so the additional consideration is that we don't want to necessarily blow-up on the first issue we come across we need to collect up errors/warnings and display them at the end.

So we have a couple of distinct classes to think about:

App Errors:

Programming errors (unexpected issues)
App errors e.g. fatal errors from running the code (e.g. a zip can't be unpacked at all).

Validation output:

Validation warnings.
Validation errors.

The first being more likely to be exception based - the latter something like a list of objects that we can process at the end. Albeit in some case we might not complete the entire validation run because of an earlier error.

—
Reply to this email directly orview it on GitHub(#12 (comment)).

[muffinresearch]

Ok I think we're good here. Closing.