obs-websocket-dotnet
obs-websocket-dotnet copied to clipboard
[ISSUE] Writing error messages directly to Console is bad form
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:
- Write a console app with an intentional UX
- Make an error happen on the OBS connection
- 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.)