Implements #575 Better error handling via the new options 'error' and 'processSource' #640
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Closes #575 Better error handling via the new options
errorandprocessSourceFrom the readme:
Options
errorThe error handler function used for the<%=construct and<%-construct. When an error is thrown within these constructs, the error handler iscalled. It receives two arguments:
err(typeunknown), which is the error objectthat was thrown; and
escapeFn(type(text: string) => string), which is the currentfunction for escaping literal text. The error function may return a
string, and if itdoes, that value is inserted into the template instead.
processSourceCallback that is invoked with the generated source code of thetemplate, without the header and footer added by EJS. Can be used to transform the source.
The callback receives two arguments:
source(string), which is the generated source text;and
outputVar(typestring), which is the name of the variable that contains the templatetext and can be appended to. The callback must return a value of type
string, which is thetransformed source. One use case for this callback is to wrap all individual top-level statements
in try-catch-blocks (e.g. by using a parser such as
acornand a stringifier such asastring)for improved error resilience.
Error handling
In an ideal world, all templates are valid and all JavaScript code they contain
never throws an error. Unfortunately, this is not always the case in the real
world. By default, when any JavaScript code in a template throws an error, the
entire templates fails and not text is rendered. Sometimes you might want to
ignore errors and still render the rest of the template.
You can use the
erroroption to handle errors within expressions (the<%=%>and
<%-%>tags). This is a callback that is invoked when an unhandled erroris thrown:
The code above logs the error to the console and renders the text
2 ERROR.Note that this only applies to expression, not to other control blocks such
as
<%if (something.invalid) { %> ... <% } %>. To handle errors in these cases,you e.g. can use the
processSourceoption to wrap individual top-levelstatements in try-catch blocks. For example, by using
acornandastringfor processing JavaScript source code:
The above code logs the error to the console and renders the text
2 STATEMENT_ERROR.