> If it's server, you need to re-create all the condition to hit it.` This means what you actually need is a real logger, not assert.
`assert` is not a logger and cannot replace a logger. A nice example of logger is [chronicles](https://github.com/status-im/nim-chronicles) Yes, reproducing production environment (or complex stateful environment) is **unrealistic**. There are many situations that are resource-consuming or impossible to simulate. That is the reason why a logging system is required in production. `assert` in general may not even has effect in production (though Nim only turn off assert in danger mode). > And if it's in logs, you can't re-create it, and had to guess what's wrong > with a or b. Speaking from my experience, it usually not enough to merely know the value of two variables and then be able to debug. There is usually a much larger **context** in order to know **why** it went wrong. Since you have mentioned a server, which I assume web server, a robust logger system should start from logging session ID for each request and then record the branching history and accumulate reasonably-sized variables and the return status. Steam the log (in json usually) at the end of request or on error to monitoring system and search engine (e.g. ELK). I somehow agree that this is boring work, but this is valuable to quickly respond to incident and trace back only-production-seen bugs. > Or, if it's not desirable for the assert default behavior, allow to extend it > with assert_hook, something like when compile(assert_hook(a, b)): > assert_hook(a, b) IMO, please don't do that. If someone want a very very powerful assertion, put that in nimble.
