Closed peschkaj closed 2 years ago
In this case, I think the solution should have a different shape - from even the name down to schema is based around exceptions, and not general logging which only has a string (or other structure). The general usage I'd prescribe here would be too only log exceptions to Exceptional, and general purpose logging to another path/location (e.g. if we had an ILogger
implementation as in #135, it'd only work for exceptions).
To support this, we'd have to change the serialization and schema for all users, support both current and future schemas in the lib (consider rolling upgrades) at a minimum, all while eating a lot of overhead to log a string, in most cases. IMO, there are many solutions out there for this (Serilog, etc.) so Exceptional mutating into a general logger wouldn't cover new ground and I'd definitely advise going that route.
In looking at logging across a lot of platforms now, it's very expensive, much more than it needs to be. I'd be remiss if we added to this path by bending something never intended for it - if we're doing high scale logging, it should be through an efficient path as Exceptional tries to take with exceptions (and only that) today. Happy to hang on this if it helps.
It would be helpful to add log levels to exceptions so they can be filtered.
I propose adding (these match with the names in use in Microsoft.Extensions.Logging.LogLevel:
Optionally, we can add
None
to get things to match perfectly.The general shape of the solution:
Error
class to support logging levels.Exception
to provide helpers for setting the log level (e.g.,myAwfulException.Warning()
)Critical
by default.