[ISSUE] Writing error messages directly to Console is bad form

[DrEsteban]

Issue Type

• Support Issue

Describe the issue https://github.com/BarRaider/obs-websocket-dotnet/blob/b8ae595e243a601be0da01c66f1e97c80282adad/obs-websocket-dotnet/Events.cs#L522-L526

The package follows a pattern of directly writing to Console when errors occur. This is highly undesirable, especially for those who are writing console-based apps and would like to handle that experience differently.

To Reproduce Steps to reproduce the behavior:

1. Write a console app with an intentional UX
2. Make an error happen on the OBS connection
3. See the error message directly interrupt the UX

Expected behavior The library should provide an ILogger-based way of handling error logs. This improves UX concerns, as well as makes error messages actually useful for users, as they now have an opportunity to intercept them in-code.

Screenshots N/A

Versions Latest, as of 5/21/2024

Additional context

I'm programmatically creating some input sources using this library, which results in Unsupported Event: InputSettingsChanged <payload> being written to console with no way to disable it... This is extremely frustrating as I'm writing a console app and it's polluting my output. As a general best practice, libraries should NEVER blindly write to the Console - that's the whole reason the ILogger<> abstraction exists.

Worse yet, the library doesn't even provide a mechanism to allow consumers to implement/handle "unsupported events" themselves. So there's literally no way for me to prevent this output from happening, despite the fact it's a "supported scenario" in the library. (Creating input sources programmatically.)