You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Currently Debug-Chan does not offer diagnostic levels. For many projects, will not scale.
Ideas:
Severity/LOD in general is not a great concept. A severity of 0, 1, 2, ... does not mean much. However, users may assign meaning to these (accept custom enums if easy enough)
Debug-Chan is a logging tool. Its primary purpose is offering information beyond warnings and errors (happy to keep warnings and errors in the Unity console)
Logging from public/protected/private... channeling based on this would be somewhat meaningful; don't think C# diagnostics include this but can get at it.
If there's a need to refine the debug chan APIs, how I see it -
A log message expressing actual change (data write) is informative
A log message clarifying control, but no mutation, is diagnostic
Two-level messages including informative + diagnostic component may be good
A QA API may be helpful to log key milestones which are also useful for validating features (as opposed to investigating issues)
Ordinarily, we do not want objects to log when they can be described as "doing nothing" (quiescence rule) - that is, unless we think they should be doing something.
The core API should avoid overreach (log the way you want!); maybe attaching an int representing a channel / target will suffice; still, an optional API normalizing a good approach?
The text was updated successfully, but these errors were encountered:
Currently Debug-Chan does not offer diagnostic levels. For many projects, will not scale.
Ideas:
If there's a need to refine the debug chan APIs, how I see it -
QA
API may be helpful to log key milestones which are also useful for validating features (as opposed to investigating issues)The core API should avoid overreach (log the way you want!); maybe attaching an int representing a channel / target will suffice; still, an optional API normalizing a good approach?
The text was updated successfully, but these errors were encountered: