debugging a windows service, adding db logging to catch cluase a bad idea?

Hi,

I have a windows service I am trying to debug.

Is it a bad idea to add error logging in the Catch() clause?

My logging is using a database to log the errors btw.

From stackoverflow

• It depends on the code. On some of my services, I log information to the database (because that is the policy here), but I have a secondary logging mechanism that add messages to the event log in the event that logging to the database fails. The question you have to ask yourself is "what happens to the erros if you can't connect to the database?"

• I'm not 100% clear and what you're trying to do as you mention both debugging and logging.

  Logging on the catch clause is generally a good idea if part of an overall logging approach.

  if you are after debugging the service you have two option - if you can control when the code you are trying to debug from outside the service (via some external stimulus) or if you have some time before the code is executed, you can simply open the source code in VS and, as long as you've compiled in debug mode you can attach VS to the service process.

  Then any breakpoints set in your source code would give you access to the code in debug,.

  If, however, you can't do that (for example if you need to debug the start event) you can add System.Diagnostics.Debugger.Break() to the source code which would start a debugger when this line is hit at runtime.

  I usually wrap such statements in an #if #endif area controls by a compile symbol.

• In the services I am responsible for, any errors that happen after initialization (after the code has confirmed it can connect to the database, has access to the log file, and starts its work) gets put into its log file. Errors that occur on startup or shutdown get sent to the event log.

• In general, logging of exceptions is a good idea. Especially when debugging services, which is always a nasty task.

  The only problem you can have is that the logging itself causes an exception. This happened to me when I was logging to the event log (see this question for details). It means that you get no information on the exception that caused your service to fail.

  For debugging purposes, I think it is useful to log exceptions into a local text file, additional to any other logging you do. That is the least likely to fail. When you are through with the debugging, you can remove those additional logging commands. (Well, you have to be careful not to introduce new error when doing that...)