runtime.newErrorObject is used to implement the Error constructor, and as such
it takes input from JavaScript via calls like `new Error('xxx')`. The actual
underlying error information is stored in an ottoError object, which is
constructed using newError. newError takes a couple of mandatory arguments,
then treats the remaining parameters (collected as `in ...interface{}`) as a
printf-style format string and parameter list, which it uses to populate the
message field of the returned ottoError object. newErrorObject was passing the
message parameter from the Error function exposed to JavaScript directly
through to newError as the first optional parameter, which led to it being
treated as a format string, which resulted in any code like `throw new
Error('%s')` behaving incorrectly, with the resultant error having a message
like "%!s(MISSING)".
This change fixes this behaviour in the least intrusive way I could find, and
adds some tests to make sure it doesn't come back.
The logic for newErrorObject and newErrorObjectError are very similar, so it
was tempting to try to merge them, but it appears they're used in somewhat
fragile ways with very little test coverage so I'll leave that as a problem
for another day.
Enable more linters, address the issues and do a major naming refactor
to use golang lower camelCase identifiers for types, functions, methods
and variable names.
Also:
* Clean up inline generation so it doesn't rely on temporary variables.
* Remove unused functions generated by inline.pl.
Enable the whitespace linter and fix the errors resulting from it.
Also:
* Remove unneeded golangci-lint config for disabled linters.
* Correct test number for panic in previous commit.
Leverage github actions for tests and linting.
This includes fixing a bunch of issues highlighted by golangci
including:
* Dead code.
* Ineffectual assigns.
* Goto warnings.
* Nil return err.
* Reused literal strings.
* Test parameter order.
Also:
* Setup clog.
This change adds a handful of functions to `otto.Otto` type that make
it easier to create proper `Error` values from native code. Previously,
the only way to do this was to call the error's constructor from
JavaScript like `vm.Call("TypeError", "message")`. `Call` can fail for
various reasons, and also modifies the current call stack.
These new functions can't fail, and since they don't involve any
JavaScript execution, won't modify the call stack. The new functions
are:
* `MakeCustomError(name, message string) Value`
* `MakeRangeError(message string) Value`
* `MakeSyntaxError(message string) Value`
* `MakeTypeError(message string) Value`
`MakeCustomError` creates an `Error` object with a specific `name` value.
The other functions cover some common error types, and call specific
functions in the runtime to construct errors with the correct prototypes.
If we need to implement any other error types, it'll mostly be copy/paste.
