Sorry Sam, I meant to say "diagnostic" where I wrote "debugging". Also, I wasn't answering your original question; rather I was questioning Kirk's assertion that the client should do all logging and not the library.
If I was diagnosing a problem in the field on some product that used your library, I would want to be able to rule out your library as the cause of the observed problem. That would require your library to have some mechanisms internally that could be used to do a field diagnostic. Think about Star Trek: when something breaks on the Enterprise, Picard got them to run a "level one diagnostic on it". The best way that I have found for solving these types of problems is to have some internal tracing / logging functionality inside your library. Ideally this type of functionality could be enabled by the user on demand. Even better would be if there would be a nice way to force the diagnostic to happen, and to have it mail the result of the diagnostic back to me so that I could examine the results for myself. The diagnostics could also do stuff like detect whether your library's caller is not calling you correctly. This would be the role of custom exceptions thrown by your library (e.g. you tried to open a database connection without specifying the connection string). But would throwing an exception be the right solution in these cases? How would it help you diagnose the case above? I think that there is a very good use of logging inside of a library to help diagnose these types of issues in the field. Perhaps an interesting solution would be to have a mechanism whereby you could switch on the fly from throwing custom exceptions to logging the result of your custom exceptions so this could aid in diagnosis (especially remote diagnosis). Am I making any sense here? -John http://www.iunknown.com -----Original Message----- From: Sam Gentile [mailto:[EMAIL PROTECTED]] Sent: Tuesday, May 28, 2002 8:54 PM To: [EMAIL PROTECTED] Subject: Re: [DOTNET] Need a good real-world C# Exceptions Resource or Stategy for Library I don't know what you mean by logging John. Its not about debugging. To me, it comes down to this: I'm making a library of useful .NET functions mainly around System.Xml stuff. There are a bunch of things that could go wrong. I think those things should be caught. I think it would be really crappy to have the runtime catching those errors and throwing stack traces. Why is this even debatable? All libraries written to this point have asserts and all sorts of error checking. I'm trying to ask about the best way to catch errors and deal with them. Sam Gentile Co-Author Wrox Professional Visual C++.NET (ISBN 1861005962 ) [EMAIL PROTECTED] www.project-inspiration.com/sgentile http://www.project-inspiration.com/sgentile/DotNet.htm BLOG: http://radio.weblogs.com/0105852/ http://www.project-inspiration.com/sgentile/ScienceFiction.htm -----Original Message----- From: dotnet discussion [mailto:[EMAIL PROTECTED]] On Behalf Of John Lam Sent: Tuesday, May 28, 2002 8:40 PM To: [EMAIL PROTECTED] Subject: Re: [DOTNET] Need a good real-world C# Exceptions Resource or Stategy for Library Actually, I'm not sure that I agree that the library should not do *any* logging. If I want to debug a library in the field, I would want to have mechanisms whereby I could enable logging in my library (reading a registry key, presence of an environment variable etc). -John http://www.iunknown.com -----Original Message----- From: Kirk Jackson [mailto:[EMAIL PROTECTED]] Sent: Tuesday, May 28, 2002 8:19 PM To: [EMAIL PROTECTED] Subject: Re: [DOTNET] Need a good real-world C# Exceptions Resource or Stategy for Library Sorry, I misunderstood what you meant by 'handling'. Yeah, I agree that the client should do any logging, rather than the library. Kirk -----Original Message----- From: franklin gray [mailto:[EMAIL PROTECTED]] Sent: Wednesday, 29 May 2002 10:14 a.m. To: [EMAIL PROTECTED] Subject: Re: [DOTNET] Need a good real-world C# Exceptions Resource or Stategy for Library "With the libraries we create, we try to make the exceptions that a library client receives meaningful." so you create custom exceptions....I bet just like I said below. ".. so that the client knows that they are catching all meaningful application exceptions:" The client knows of all exception if the catch them like they should and it should be their responsibility to log them if they feel the need to, otherwise you are eating up their harddrive space for no reason. You can read messages from the DOTNET archive, unsubscribe from DOTNET, or subscribe to other DevelopMentor lists at http://discuss.develop.com. You can read messages from the DOTNET archive, unsubscribe from DOTNET, or subscribe to other DevelopMentor lists at http://discuss.develop.com. You can read messages from the DOTNET archive, unsubscribe from DOTNET, or subscribe to other DevelopMentor lists at http://discuss.develop.com. You can read messages from the DOTNET archive, unsubscribe from DOTNET, or subscribe to other DevelopMentor lists at http://discuss.develop.com. You can read messages from the DOTNET archive, unsubscribe from DOTNET, or subscribe to other DevelopMentor lists at http://discuss.develop.com.
