Closed ImogenBits closed 11 months ago
Thank you, do I read the changes correctly that the default option for logging now does not reveal the description of an error?
No, this follows our current policy of making the default options the ones that better suit local development. In this case this means more detailed error messages, etc. However, the web framework does then override the runtime options to ensure a safe match environment, these will be added to that.
Also, is it intentional that you bumped the version number in this branch and not main? I think I would also go with version 4.1.0 since this does add new features.
Okay, thank you for clarifying that the web server overwrites this behavior.
The version bump inside this PR was intended to be economical, as I wanted this PR to mark the next release. I do however see now that this was not very wise, as the intended next version may well change in the mean time. Just as not to make the situation even messier, I will bump the version inside this PR up to 4.1.0 as suggested and create separate PRs for version increments in the future.
This updates the json match logs in two ways: Firstly, it addresses #144 by adding the option to only include the "message" part of each raised error, and not the "detail". This stops user code from intentionally crashing and outputting hidden data. Secondly, it adds options that let you include program output in the match result. These options are intentionally formatted in a somewhat strange way to leave room for future expansion. The current implementation only does the most straightforward part of this general idea, but should cover most use cases.