It's difficult to track down template errors #27
Comments
|
Can this solve the problem? |
|
I will add the template name later. |
Can you describe how that would help? What do you expect users to do with it? I think that clear error messages should be provided by default, without doing any extra work. |
|
By default, undefined variables render as an empty string or throw an error when accessing members. With this setup, users can either throw an error or create an undefined object like in the example above. For example: import 'package:jinja/jinja.dart';
const String source = '''
{{ user.name }}''';
Object? undefined(String name) {
throw UndefinedError('$name is not defined.');
}
void main() {
var environment = Environment(undefined: undefined);
var template = environment.fromString(source);
print(template.render());
// Unhandled exception:
// UndefinedError: user is not defined.
}Currently, I don't track which template is active (inlcude, inheritance, blocks, macro calls) and don't save variable locations in the AST to provide more information. Planned for the next version. |
|
Here's another example: There's a variety of these. But I wanted to further make the point that it's pretty much impossible to know what these errors mean, or what a user is supposed to do about it. I end up just randomly changing things until the error goes away. That costs quite a bit of time. This error, for example, could output at least a fragment of the template code that it failed to parse, so that I have some idea of what I'm looking for. |
|
I just found myself working through another instance of this friction: As you can see, these errors are easy to cause, and very difficult to root cause. I thought that it might help me to print out all the variables that are expected by a given But the only thing that |
|
For variables used in the template, do you need something like this? class Template {
List<String> get variables;
}Working on |
|
@ykmnkmi that would be helpful. Though it would probably be useful to get the fully qualified variable path. If the template tries to access |
|
I see only the |
I don't know what that means. But if my template tries to access |
|
In the |
|
I don't know what you mean by "should". What I'm saying is that it's very difficult to track down which template variable is causing the template renderer to blow up. I just want to be able to find the source of a problem and fix it. If you make that possible, then I'm happy. If I still can't find the source of the error, then I'm not happy. |
|
I mean expected implementation. |
We're using
jinjain our static site generator called Static Shock.In general we're very happy with this implementation of Jinja. It provided us with a reasonable templating library for our use-cases.
However, there's one perpetual difficulty, which is tracking down the root cause of template generation failures. Most situations where we've misconfigured a template result in error messages and stacktraces that don't help us locate the issue.
Here's an example of an error I just ran into. The reason this error is happening is because I screwed something up, but it's difficult to figure out what I screwed up:
Any time I see "null" I know that I probably didn't provide a value for a property that's used in the template. But who knows which template variable that is, or where I screwed up.
It would be a big help if someone could take a pass over this package and ensure that every possible error condition in a template comes with a clear message about what went wrong, and where.
For example, imagine that the above error message said:
The text was updated successfully, but these errors were encountered: