Home | Contact Us | FAQ | Search & Site Map | Link to Us
Sign In | Join | Other 45 Sites in Network
HomeAnnouncementsFree MagazinesWhite PapersSubmit Content
Discussion GroupsASP.NETWindows FormsLanguages.NET FrameworkVisual Studio.NET
Articles.NET FrameworkASP.NETToolsWindows Forms
.NET DirectoryOpen Source ProjectsUser GroupsWeb Resources
Related Topics
Visual Basic 6SQL ServerMS AccessOther DB ProductsMS Server ProductsMore Topics ...

.NET Forum / Languages / C# / November 2005

Tip: Looking for answers? Try searching our database.

Logging messages in a class based on who is using it...?

Thread view: 
Enable EMail Alerts  Start New Thread
Thread rating: 
JohnW - 30 Nov 2005 18:35 GMT
Hi,
I'm not sure of the terminology here but...

I have a standalone assembly (Foo) and I log errors using a simple call
in my "catch" blocks: e.g.

class Foo
...
public DoSomething()
{
...
catch
{
LogError("blah", Severity.Error, etc....);
}
...
void LogError(msg,sev,...) { output.write(...) }
...
This assembly DLL will be referenced by other assemblies however each
of these calling assemblies may wish to log any errors their own way.
Can I make it so that the calling assembly somehow "overrides" the
LogError calls and writes the errors however it wishes. Ideally I'd
like:

using Foo
class Bar
...
Foo.DoSomething()
...
void LogError(msg) { showpopup(msg) }   <--(I want THIS LogError to run
when DoSomething goes wrong)

I'm looking at interfaces, abstract classes, virtual functions, etc.
but I'm not inherting anything here - just making calls to an assembly.

Hope someone can help.

Thanks.
Michael Nemtsev - 30 Nov 2005 18:41 GMT
Hello JohnW,

A bit off-top, why do u want to use your own logger?
There are already a lot of nice realiziation of loggers - MS Enterprise,
log4net.

J> Hi,
J> I'm not sure of the terminology here but...
J> I have a standalone assembly (Foo) and I log errors using a simple
J> call in my "catch" blocks: e.g.
J>

---
WBR,
Michael  Nemtsev :: blog: http://spaces.msn.com/members/laflour

"At times one remains faithful to a cause only because its opponents do not
cease to be insipid." (c) Friedrich Nietzsche
JohnW - 30 Nov 2005 18:52 GMT
Hi,
Well that's the thing - I want calling apps to be able to use those
loggers if they want to. My own logger is just basic.

Thanks.
John Wood - 30 Nov 2005 19:28 GMT
You could probably pass in the 'this' pointer to the log call, and have the
logging method check in the passed-in object for a specific interface, or
look for a specific class name in its assembly (or class with a specific
attribute) that will provide the overridden logging functionality. If it
doesn't find it, it just falls back to default behavior of writing to that
file. That's the least intrusive solution I can think of right now.

> Hi,
> I'm not sure of the terminology here but...
[quoted text clipped - 34 lines]
>
> Thanks.
Anders Norås - 30 Nov 2005 22:46 GMT
You can use an event to allow client code to be notified whenever something
needs to be logged.
The example below shows a naïve implementation of this. You'll have to write
your own EventArgs implementation to contain the information to be logged.
public class MyClass
{
    public void MyMethod()
    {
        try
        {
            throw new ApplicationException("Something went wrong");
        }
        catch
        {
            OnLog(new EventArgs());
        }
    }
    private void OnLog(EventArgs e)
    {
        if (Logging!=null)
        {
            Logging(this,e);
        }
    }
    public event LoggingEventHandler Logging;
    public delegate void LoggingEventHandler(object sender, EventArgs e);
}

Anders Norås
http://dotnetjunkies.com/weblog/anoras/

Free Magazines

Get these publications absolutely FREE for up to 12 months. There are no hidden fees and no obligation. Simply choose a title, complete the application form and submit it. Read more ...

Oracle MagazineNetwork ComputingComputer WorldBio-IT WorldeWeekInformation WeekInfosecurity
 
Sign In
Join
My Latest Posts
My Monitored Threads
My Blog
My Photo Gallery
My Profile
My Homepage

Start New Thread
Enable EMail Alerts
Rate this Thread



©2008 Advenet LLC   Privacy Policy - Terms of Use
This website includes both content owned or controlled by Advenet as well as content owned or controlled by third parties.