If an error message falls in a forest...
-
@JvdL said:
A logger that would require a stream parameter, as you suggest, makes for less capable and more complex system. Logging would be practically unconfigurable. The EXE would need to pass a stream parameter to every method in every class in every DLL, and so forth down the chain because any method might some day want to do some logging.
Every method? Whats wrong with only passing it when you initialise a class. It's not that much more complicated, and makes the shared library more configurable, not less.
@JvdL said:
Logging to non-streams (email, SMS, event monitors) would be impossible.
Whoever designed your logging framework is a moron anyway. You are not logging stream data; you are logging messages. Design a message handler interface and write a handler for streams, email, sms, whatever. Then, your logging framework doesn't have to give a shit about where it's sending data, just that its sending the correct priority message to the correct handler. Whether it is a stream or an email no longer makes any difference.
-
-
@Salamander said:
@JvdL said:
Logging to non-streams (email, SMS, event monitors) would be impossible.
Whoever designed your logging framework is a moron anyway. You are not logging stream data; you are logging messages. Design a message handler interface and write a handler for streams, email, sms, whatever. Then, your logging framework doesn't have to give a shit about where it's sending data, just that its sending the correct priority message to the correct handler. Whether it is a stream or an email no longer makes any difference.
That moron is me and it is designed more or less the way you describe. To log, call
Logger.Warning("{0} is a moron because {1}", jvdl, designException);
The logger will handle such an invocation based on the severity (warning), the category derived by logger from CallingAssembly attributes and reflection. When sevcat merits logging, it compiles a message with time stamp, log text, user, source, machine, stack traces. It dispatches that to one or more handlers associated to that sevcat.
This has now been forbidden by the console police. According to them, every possible entry point needs to bootstrap the Logger with a std I/O reference wrapped in a TextWriter stream, regardless of whether the Logger will use it or not, or whether Logging is used at all. That's a fantastic design, especially for web apps that have thousands of entrypoints. Reminds of my Java days on Tomcat & Log4J. Fifteen years ago that was passable or maybe today when you get paid per line of code.Thanks but no thanks.
-
blakeyrat, what are you feelings on shared libraries using System.Diagnostics.Debug?
-
Look, if you've already decided you don't agree with Morbs and I, why the fuck are you posting here?
Fine you don't agree. Congratulations. There's no trophy.
-
@ShatteredArm said:
blakeyrat, what are you feelings on shared libraries using System.Diagnostics.Debug?
I'm sure your intent here is that I say, "I think that's fine, since Debug is not a user interface class". Then you jump on me, and go, "AHA BUT YOU CAN REDIRECT System.Diagnostics.Debug TO WRITE OUT TO THE Console! I GOTCHA! GOTCHA GOOD SUCKER!" Then I start crying and go hide under the swing set and my teacher has to come out with some extra cupcakes from the cafeteria and gently talk me into going back to class, but she lets me play with the Legos in the back instead of paying attention.
Right?
-
@blakeyrat said:
Then I start crying and go hide under the swing set and my teacher has to come out with some extra cupcakes from the cafeteria and gently talk me into going back to class, but she lets me play with the Legos in the back instead of paying attention.
Mmmmmm....cupcakes.
-
@JvdL said:
1. One DLL is dedicated to logging. It has logging categories and severity. Not satisfied with standard tools in the market, it is a re-invented wheel that can log to a variety of devices: files, databases, MS event viewer, HP openview, email, SMS, stderr or stdout. The destination depend on category and severity of the logged message and the IT environment. This is configured by the sys admin. It bootstraps autonomouly and by design it has more authority then the EXE as to where and how it logs. This reflects the requirement that a sys admin (an IT person) has more authority on logging than an app admin (usually a business person).
I would say in a logging library, it's probably okay (although it's still an exception because, seriously, how many people should be writing their own logger?) The thing is, if you know the logging library is going to write to stdout, then that's a pretty clearly spelled-out dependency. "You using the logging library? Yeah? Just beware, that bastard can write to stdout."
That said:
@JvdL said:
A logger that would require a stream parameter, as you suggest, makes for less capable and more complex system. Logging would be practically unconfigurable. Logging to non-streams (email, SMS, event monitors) would be impossible. The EXE would need to pass a stream parameter to every method in every class in every DLL, and so forth down the chain because any method might some day want to do some logging.
I really don't see that as the case. You have multiple logging backends (email, SMS, event monitors and streams). The EXE can just instantiate a new Stream backend with stdout as the stream and pass it to the logger to add to its collection of backends. It doesn't require stdout to be hard-coded nor for a stream to be explicitly passed to a bunch of functions. And it doesn't break your backend interface because each backend type just takes a message, that's all. What it does with that message (fires off an email, sends an SMS, writes to a stream--file or stdout) is completely internal to the implementation.
@JvdL said:
2. I'm not a big proponent of unit testing and piss on tools like NUnit but do apply testing to numeric algorithms, some of which are internal. So some DLL come with embedded unit tests. The test methods use stdout to indicate what they test, the input, the output. The DLL have one public test entry point that runs all the internal tests. To test a particular unit, one sets up data in a DB, uses the test app to run the public test of the DLL that contains the unit and pipes the output to a grepper that fishes out the results relevant to the unit. This can be done in development and in production. Std I/O makes this very easy, both to write code and to run tests.
I don't consider unit tests to be a program. Really, the rules that apply to writing good applications are not the same as the rules for writing good unit tests. Unit tests are not mean to be used as libraries that are linked by multiple applications.
As Blakey and I said before, there are obviously exceptions. However, a lot of those exceptions already have their own project types or what-have-you. How hard is it to distinguish between a "normal" library and a unit test, logging library or curses-esque library? And a "normal" library should not need to write to stdout. In fact, this is pretty standard; I can't think of any "normal" Unix libraries that write directly to stdout.
-
@JvdL said:
stuff
You're not describing a shared library. You're describing a logging library that is designed specifically for your application (or several versions of the same application). This is a different concept than releasing a library to the Internet and saying "Use this for whatever you like".
-
@JvdL said:
According to them, every possible entry point needs to bootstrap the Logger with a std I/O reference wrapped in a TextWriter stream, regardless of whether the Logger will use it or not, or whether Logging is used at all.
Presumably you're using a config to tell you where to log. In which case, if the config says "Use stdout" then that's fine--it's a case of the user (or the user's admin) making that decision. The problem comes in when you have a library that's writing to stdout where there's no way to control that behavior, not from within the program itself nor as a user.
@JvdL said:
That's a fantastic design, especially for web apps that have thousands of entrypoints.
O_o Most web apps I've seen only have a handful of entrypoints and use a router to route requests to the proper controllers.
-
@lettucemode said:
@JvdL said:
stuff
You're not describing a shared library. You're describing a logging library that is designed specifically for your application (or several versions of the same application). This is a different concept than releasing a library to the public and saying "Use this for whatever you like".
I think it's a shared library. The thing is, it's not a "normal" library. Furthermore, it sounds like the logging destinations can be set by an admin, which is fine--if the user/admin can disable writing to stdout with a config option, I don't consider that a problem.
-
@blakeyrat said:
@ShatteredArm said:
blakeyrat, what are you feelings on shared libraries using System.Diagnostics.Debug?
I'm sure your intent here is that I say, "I think that's fine, since Debug is not a user interface class". Then you jump on me, and go, "AHA BUT YOU CAN REDIRECT System.Diagnostics.Debug TO WRITE OUT TO THE Console! I GOTCHA! GOTCHA GOOD SUCKER!" Then I start crying and go hide under the swing set and my teacher has to come out with some extra cupcakes from the cafeteria and gently talk me into going back to class, but she lets me play with the Legos in the back instead of paying attention.
Right?
Or depending on what the consuming application is doing, writing to Debug could cause the application to crash. Since you already see the parallels, my work is done. All that's left is whether you actually believe it's OK to use Debug in a shared library.
-
@JvdL said:
Logger.Warning("{0} is a moron because {1}", jvdl, designException);
The logger will handle such an invocation based on the severity (warning), the category derived by logger from CallingAssembly attributes and reflection. When sevcat merits logging, it compiles a message with time stamp, log text, user, source, machine, stack traces. It dispatches that to one or more handlers associated to that sevcat.
Sensible at this stage. Now let's pose the next question: What configures where the severity categories go? Does the framework itself dictate that these go to the console, or are you instead providing this from the calling Application when you initialize your logging framework (Either via configuration settings or programatically creating handlers for the levels)? If your framework takes it upon itself to decide to write it's errors to the stderr then you bet I'd disagree. If your framework is instructed by your calling code that errors at severity X go to stderr, so be it because then it's told you to do so.
You seem to have described your logging framework as dictating where thngs go, so in that regard I would say that either you shouldn't touch the UI from it or alternatively the application should (By configuration, parameters to a constructor, static methods, inherting a logger and implementing methods, or some variety of mystic voodoo chant) provide the logging framework with a mechanism for showing the error to the user. The fact the Logging layer may be deciding whether to show it is one thing, but the decision of whether "Show it on the UI" means it should be put into a HTML box with a red border, shown in a popup dialog above your forms application, written to standard error or printed out and strapped to the leg of a carrier pidgeon with instructions to deliver it to the user is a decision the UI layer should be making.
-
@ShatteredArm said:
Or depending on what the consuming application is doing, writing to Debug could cause the application to crash.
Isn't that a pretty good reason to not include it in a shared library?
-
@morbiuswilters said:
@ShatteredArm said:
Or depending on what the consuming application is doing, writing to Debug could cause the application to crash.
Isn't that a pretty good reason to not include it in a shared library?
Not necessarily. For a call to Debug to cause the application to class, the consuming application would have to be doing something beyond stupid. You could argue that having those Debug calls there could provide enough benefit to justify the risk of some application using a totally inappopriate debug listener. It would be completely stupid to force all consuming applications to provide their own streams for debugging messages, just because some idiot might be using the standard Debug trace in a boneheaded fashion.
