3 ms·
In practical terms there's pros & cons I guess, but in general doesn't loading a Context with session variables make code more concise and easier to understand
by euroderf 3y ago
In practical terms there's pros & cons I guess, but in general doesn't loading a Context with session variables make code more concise and easier to understand ? DB connections, loggers, and the like. If you really want to pass around Context's in all your API signatures then at least try to make the most of it.
Are pitfalls ever actually encountered ?
- preseinger 3y agoif you pass a logger to a foo as a parameter to the foo constructor, then missing a logger is a compile-time error if you pass a logger to a foo as a parameter in the request context, then missing a logger is a run-time error
- euroderf 3y agoFer sher. But a passed-by-Context logger could be used (for example) to override a library package's default (stdlib?) logger. But what is the SOP / Best Practice here ? Do many libraries have some sort of SetLogger(..) initialization call, so that loggers don't clutter the API ? Or are error returns info-(over-)loaded ?
- preseinger 3y agoit's pretty straightforward, everything that logs takes a logger as a dependency during construction