How do fit advise doing logging? In vbInvoke I have used your logging granaries @MathieuGuindon for VBA I think I tidied it up a bit maybe and made a tB package. But I've got all this logging everywhere which is very useful to debug. I thought I could add a LogManager that implements the right interfaces but all the methods are NOOP. That would remove pretty much any performance overhead I imagine. But I'm wondering about your (plural) advice on when to include logging in a release of a package
Let's assume you have a great logging framework so any payment app that references your package can inject its own logger to configure behaviour of the logging (e.g. direct it to a file)
In other words; logging is one of the public interface of my program so should also be designed carefully.
*how do you advise doing logging
*logging granaries wtf autocorrect I meant logging framework
*any payment app = any parent app
Typing is hard...
Matt wrote an article on ambient context I should probably reread that. But maybe logging which exposes private implementation details of a package is TMI. On the other hand it can "empower" consumers of the package to trace bugs or provide logs back to me so maybe it's useful.
@MathieuGuindon Thanks I'll definitely take a look. Although the framework isn't too important to me, the functionality I would imagine is pretty similar whatever the framework (please correct me). I'm asking what your advice is on when to Log. E.g. if a theoretical RD3 VBE addin written in tB were to depend on my code (directly or forked or copy-paste I have grand ambitions), how would it like the logging interface to look? Should it even have logs?
Geez... Our entire company is having internet connection issues. Not a big deal unless you're a doctor who needs to look something up in an online EMR for your patient... Amazingly, though, our MS hosted Exchange servers seem to be pretty responsive, though Teams is sluggish.
Maybe people will start to learn that everything online all the time isn't always the best option... (only took about 10 retrys to post that message...)
e.g. It looks like RD often uses a lightweight wrapper class to add logging to the forwarded methods of some wrapped class. So the functional code is not polluted with log messages, and it is easy to remove the logging layer entirely. However I cannot tell the logic of when a class has a log wrapper vs when no logs are needed. Also for trace logs of internal implementation details of a class, I can't see how a wrapper would capture this, so maybe those log calls are less OOP more procedural
@Greedo logging is a special concern in an application, because it is "cross-cutting" - we went with DI so we're typically injecting the logger into some base class that invokes a templated abstract method that derived classes can implement without needing to care much about trace logging, ...
...while still having access to the logger if more detailed logging should be needed
there are other approaches to cross-cutting concerns; we could have used an AOP (aspect-oriented) framework to generate that logging code at compile-time for example
a tB add-in would probably have to reference at least some of the RD3 assemblies, and thus would have to be a consumer of the logging API, I think.
there's a piece missing between the add-in and the LSP server though: the Rubberduck.Client library will expose everything the add-in needs to communicate with the LSP server, so it won't need to deal with RPC and proxies at all.
I'll have to double-check if it's LSP-compliant (IIRC it is), but RD3 RPC clients will be able to send log notifications to the server through that client library, so add-in logging that could potentially trigger a TraceTelemetry event would all go through it.
That said nothing stops a client from logging its own stuff without telling the LSP server ;-)
VBA Rubberducking
VBA Rubberducking