473,699 Members | 2,835 Online
Bytes | Software Development & Data Engineering Community
+ Post

Home Posts Topics Members FAQ

Logging (exceptions etc)

Hi,

I'm getting into the Trace-functionality in .NET, using it to provide some
much-needed logging across dlls in the project we're working on. However,
being a newbie, I'm wondering if some more experienced loggers can provide
me with some ideas as to how to log in a simple yet flexible manner. For
instance, I'd like the code to be as uncluttered as possible by Trace
statements.

As an example of basic logging functionality, I've come up with some
alternatives for logging exceptions that occur in an object:

1) Wrap the throwing of an exception in a method, which can handle any
logging before throwing the actual exception.

2) Handle logging in the constructors of my own hierarchy of exceptions.
This makes the logging more transparent in the code, but doesn't work for
standard .NET exceptions such as ArgumentNullExc eption (I'd have to subtype
it).

3) Use a decorator object to wrap the original object, catch all exceptions,
write to log, and rethrow.

Any and all thoughts/comments are much appreciated!

Regards,
Einar

--
"If it was so, it might be; and if it were so, it would be; but as it isn't,
it ain't. That's logic" -- Lewis Carroll
Nov 16 '05 #1
16 2167
Hi,

Have you looked at the Exception Mangement Application Block at MSDN ?

The Exception Management Application Block provides a simple yet extensible framework for handling exceptions. With a single line of application code you can easily log exception information to the Event Log or extend it by creating your own components that log exception details to other data sources or notify operators, without affecting your application code. The Exception Management Application Block can easily be used as a building block in your own .NET application.

[ http://msdn.microsoft.com/library/de...ml/emab-rm.asp ]
Regards,
Saurabh Nandu

Nov 16 '05 #2
Hi,

Thanks for the tip. I actually did take a look at it a while ago, but at
that time I wasn't really into exception management the way I am now. I'll
take a fresh look at it, thanks.

Regards,
Einar

"Saurabh Nandu" <Sa**********@d iscussions.micr osoft.com> wrote in message
news:F8******** *************** ***********@mic rosoft.com...
Hi,

Have you looked at the Exception Mangement Application Block at MSDN ?

The Exception Management Application Block provides a simple yet extensible framework for handling exceptions. With a single line of
application code you can easily log exception information to the Event Log
or extend it by creating your own components that log exception details to
other data sources or notify operators, without affecting your application
code. The Exception Management Application Block can easily be used as a
building block in your own .NET application.
[ http://msdn.microsoft.com/library/de...ml/emab-rm.asp ]

Regards,
Saurabh Nandu

Nov 16 '05 #3
As someone else wrote, start with the MS Exception Management block. You may
need to modify/extend it but it's a pretty good starting point.

I use a strategy that boils down to this...

If it's an exception that my own code throws then if it's the 1st time that
an exception has been thrown I log it. If it's being propagated up a call
stack (this happens when a catch block catches it, wraps it in another
exception, and rethrows it), I do not log it. I detect this in the
constructor of the exception object by examining the InnerException property
value.

If the exception is thrown by an external module then the catching code must
manually call the exception publish method if it is warranted.

If the exception is crossing a boundary I log it (perhaps again) - this
ensures that exception data is never lost in case the original site that
generated the exception did not log it. You must define what the boundary
is - it can be an appdomain, machine, server, module, etc.

Another thing to look for are cases where an exception gets swallowed. While
this is considered to be "bad" it nonetheless still happens, sometimes
legitimately. We require all such cases to call a method called
SwallowExceptio n. Currently it just outputs the exception message to the
trace buffer. I've identified a number of areas in our app where exceptions
were being swallowed that never should have been generated at all.

Server-side applications has more need to log exceptions then client-side
code since they do not have access to a UI to display fault information.
Applications can always make system-wide policy decisions about logging,
unhandled exception policy, etc.

Components (libraries) have a more difficult decision to make since they are
small pieces that do not "own" a logging policy or mechanism. They may not
even have security privileges sufficient to log to a file or create an
eventlog source. If you don't know the environment a component will be used
in you cannot make assumptions about what will be available at runtime. In
this case you should only throw the exception and let the code using the
component make the decision about how to handle the exception.

There currently is no system-wide notification that is generated whenever
any exception is thrown - this is unfortunate because this would be useful
for ensuring that exceptions are always logged.

"Einar Høst" <_e*******@hotm ail.com> wrote in message
news:uw******** ******@tk2msftn gp13.phx.gbl...
Hi,

I'm getting into the Trace-functionality in .NET, using it to provide some
much-needed logging across dlls in the project we're working on. However,
being a newbie, I'm wondering if some more experienced loggers can provide
me with some ideas as to how to log in a simple yet flexible manner. For
instance, I'd like the code to be as uncluttered as possible by Trace
statements.

As an example of basic logging functionality, I've come up with some
alternatives for logging exceptions that occur in an object:

1) Wrap the throwing of an exception in a method, which can handle any
logging before throwing the actual exception.

2) Handle logging in the constructors of my own hierarchy of exceptions.
This makes the logging more transparent in the code, but doesn't work for
standard .NET exceptions such as ArgumentNullExc eption (I'd have to subtype it).

3) Use a decorator object to wrap the original object, catch all exceptions, write to log, and rethrow.

Any and all thoughts/comments are much appreciated!

Regards,
Einar

--
"If it was so, it might be; and if it were so, it would be; but as it isn't, it ain't. That's logic" -- Lewis Carroll

Nov 16 '05 #4
Thanks for your thoughts, definitely valuable input for developing my own
strategy!

Regards,
Einar
Nov 16 '05 #5
Einar,
In addition to the other comments about using the Exception Management
Block, I normally do my logging in a global exception handler. (Read I may
use the Exception Management Block in my Global Exception Handler)

Also I use try/finally & using more then I use try/catch. I only use
try/catch when there is something specific that I need to do with the
exception, otherwise I let my global exception handlers handle the
exception.

Depending on the type of application you are creating, .NET has three
different global exception handlers.

For ASP.NET look at:
System.Web.Http Application.Err or event
Normally placed in your Global.asax file.

For console applications look at:
System.AppDomai n.UnhandledExce ption event
Use AddHandler in your Sub Main.

For Windows Forms look at:
System.Windows. Forms.Applicati on.ThreadExcept ion event
Use AddHandler in your Sub Main.

It can be beneficial to combine the above global handlers in your app, as
well as wrap your Sub Main in a try catch itself.

There is an article in the June 2004 MSDN Magazine that shows how to
implement the global exception handling in .NET that explains why & when you
use multiple of the above handlers...

http://msdn.microsoft.com/msdnmag/is...T/default.aspx

For example: In my Windows Forms apps I would have a handler attached to the
Application.Thr eadException event, plus a Try/Catch in my Main. The
Try/Catch in Main only catches exceptions if the constructor of the MainForm
raises an exception, the Application.Thr eadException handler will catch all
uncaught exceptions from any form/control event handlers.

Hope this helps
Jay
"Einar Høst" <_e*******@hotm ail.com> wrote in message
news:uw******** ******@tk2msftn gp13.phx.gbl...
Hi,

I'm getting into the Trace-functionality in .NET, using it to provide some
much-needed logging across dlls in the project we're working on. However,
being a newbie, I'm wondering if some more experienced loggers can provide
me with some ideas as to how to log in a simple yet flexible manner. For
instance, I'd like the code to be as uncluttered as possible by Trace
statements.

As an example of basic logging functionality, I've come up with some
alternatives for logging exceptions that occur in an object:

1) Wrap the throwing of an exception in a method, which can handle any
logging before throwing the actual exception.

2) Handle logging in the constructors of my own hierarchy of exceptions.
This makes the logging more transparent in the code, but doesn't work for
standard .NET exceptions such as ArgumentNullExc eption (I'd have to subtype it).

3) Use a decorator object to wrap the original object, catch all exceptions, write to log, and rethrow.

Any and all thoughts/comments are much appreciated!

Regards,
Einar

--
"If it was so, it might be; and if it were so, it would be; but as it isn't, it ain't. That's logic" -- Lewis Carroll

Nov 16 '05 #6
Hi Jay,

Thanks for the input and the pointer to the article. I think I may have read
it a while ago, but I believe it's worth another look.

There are many issues related to exception handling (obviously), but
handling unhandled exceptions is actually very important to us, as we're
writing an add-in to an existing program. We don't want to bring everything
else down with us... I think the rest of the guys I'm working with should
read the article too.

Thanks again.

Einar

"Jay B. Harlow [MVP - Outlook]" <Ja************ @msn.com> wrote in message
news:eW******** ******@tk2msftn gp13.phx.gbl...
Einar,
In addition to the other comments about using the Exception Management
Block, I normally do my logging in a global exception handler. (Read I may
use the Exception Management Block in my Global Exception Handler)

Also I use try/finally & using more then I use try/catch. I only use
try/catch when there is something specific that I need to do with the
exception, otherwise I let my global exception handlers handle the
exception.

Depending on the type of application you are creating, .NET has three
different global exception handlers.

For ASP.NET look at:
System.Web.Http Application.Err or event
Normally placed in your Global.asax file.

For console applications look at:
System.AppDomai n.UnhandledExce ption event
Use AddHandler in your Sub Main.

For Windows Forms look at:
System.Windows. Forms.Applicati on.ThreadExcept ion event
Use AddHandler in your Sub Main.

It can be beneficial to combine the above global handlers in your app, as
well as wrap your Sub Main in a try catch itself.

There is an article in the June 2004 MSDN Magazine that shows how to
implement the global exception handling in .NET that explains why & when you use multiple of the above handlers...

http://msdn.microsoft.com/msdnmag/is...T/default.aspx

For example: In my Windows Forms apps I would have a handler attached to the Application.Thr eadException event, plus a Try/Catch in my Main. The
Try/Catch in Main only catches exceptions if the constructor of the MainForm raises an exception, the Application.Thr eadException handler will catch all uncaught exceptions from any form/control event handlers.

Hope this helps
Jay
"Einar Høst" <_e*******@hotm ail.com> wrote in message
news:uw******** ******@tk2msftn gp13.phx.gbl...
Hi,

I'm getting into the Trace-functionality in .NET, using it to provide some much-needed logging across dlls in the project we're working on. However, being a newbie, I'm wondering if some more experienced loggers can provide me with some ideas as to how to log in a simple yet flexible manner. For
instance, I'd like the code to be as uncluttered as possible by Trace
statements.

As an example of basic logging functionality, I've come up with some
alternatives for logging exceptions that occur in an object:

1) Wrap the throwing of an exception in a method, which can handle any
logging before throwing the actual exception.

2) Handle logging in the constructors of my own hierarchy of exceptions.
This makes the logging more transparent in the code, but doesn't work for standard .NET exceptions such as ArgumentNullExc eption (I'd have to

subtype
it).

3) Use a decorator object to wrap the original object, catch all

exceptions,
write to log, and rethrow.

Any and all thoughts/comments are much appreciated!

Regards,
Einar

--
"If it was so, it might be; and if it were so, it would be; but as it

isn't,
it ain't. That's logic" -- Lewis Carroll


Nov 16 '05 #7
If you want to avoid bringing everything else down then you cannot allow the
exception to be unhandled, especially if you are writing an add-in. You
should wrap all threads that you create in try-catch blocks.

The rules under v1.0 and v1.1 of the runtime are that if the unhandled
exception occurs on the main thread or a thread that originates in unmanaged
code the application will be terminated. You cannot change this - it is
baked into the runtime.

If the unhandled exception occurs on a thread other then this, such as a
threadpool thread, one manually started, or the finalizer thread, then an
unhandled exception event will be sent and the exception will be swallowed.
While the current implementation of the runtime does not terminate an app on
these threads there is no guarantee that this will not change, and in fact
it probably will (and should) change.

There is a flag in the event args that indicates if the app will exit - this
is a readonly indicator of what will happen to the app after the UE handler
has run to completion.

I also disagree conceptually with using the UE handler as the backstop
exception handler. It is convenient to use it that way but I consider it to
be bad practice - I prefer to wrap all threads, etc. in a try-catch, also
using specific try-catches as necessary to locally recover from errors, and
I treat all UEs as a indication that a programming error may have occurred.
I definitely log all that I get but I consider them to be bugs.

I agree with the liberal use of try-finally blocks.

regards,
Dave
"Einar Høst" <_e*******@hotm ail.com> wrote in message
news:e%******** ********@TK2MSF TNGP09.phx.gbl. ..
Hi Jay,

Thanks for the input and the pointer to the article. I think I may have read it a while ago, but I believe it's worth another look.

There are many issues related to exception handling (obviously), but
handling unhandled exceptions is actually very important to us, as we're
writing an add-in to an existing program. We don't want to bring everything else down with us... I think the rest of the guys I'm working with should
read the article too.

Thanks again.

Einar

"Jay B. Harlow [MVP - Outlook]" <Ja************ @msn.com> wrote in message
news:eW******** ******@tk2msftn gp13.phx.gbl...
Einar,
In addition to the other comments about using the Exception Management
Block, I normally do my logging in a global exception handler. (Read I may
use the Exception Management Block in my Global Exception Handler)

Also I use try/finally & using more then I use try/catch. I only use
try/catch when there is something specific that I need to do with the
exception, otherwise I let my global exception handlers handle the
exception.

Depending on the type of application you are creating, .NET has three
different global exception handlers.

For ASP.NET look at:
System.Web.Http Application.Err or event
Normally placed in your Global.asax file.

For console applications look at:
System.AppDomai n.UnhandledExce ption event
Use AddHandler in your Sub Main.

For Windows Forms look at:
System.Windows. Forms.Applicati on.ThreadExcept ion event
Use AddHandler in your Sub Main.

It can be beneficial to combine the above global handlers in your app, as well as wrap your Sub Main in a try catch itself.

There is an article in the June 2004 MSDN Magazine that shows how to
implement the global exception handling in .NET that explains why & when

you
use multiple of the above handlers...

http://msdn.microsoft.com/msdnmag/is...T/default.aspx

For example: In my Windows Forms apps I would have a handler attached to

the
Application.Thr eadException event, plus a Try/Catch in my Main. The
Try/Catch in Main only catches exceptions if the constructor of the

MainForm
raises an exception, the Application.Thr eadException handler will catch

all
uncaught exceptions from any form/control event handlers.

Hope this helps
Jay
"Einar Høst" <_e*******@hotm ail.com> wrote in message
news:uw******** ******@tk2msftn gp13.phx.gbl...
Hi,

I'm getting into the Trace-functionality in .NET, using it to provide

some much-needed logging across dlls in the project we're working on. However, being a newbie, I'm wondering if some more experienced loggers can provide me with some ideas as to how to log in a simple yet flexible manner. For instance, I'd like the code to be as uncluttered as possible by Trace
statements.

As an example of basic logging functionality, I've come up with some
alternatives for logging exceptions that occur in an object:

1) Wrap the throwing of an exception in a method, which can handle any
logging before throwing the actual exception.

2) Handle logging in the constructors of my own hierarchy of exceptions. This makes the logging more transparent in the code, but doesn't work for standard .NET exceptions such as ArgumentNullExc eption (I'd have to

subtype
it).

3) Use a decorator object to wrap the original object, catch all

exceptions,
write to log, and rethrow.

Any and all thoughts/comments are much appreciated!

Regards,
Einar

--
"If it was so, it might be; and if it were so, it would be; but as it

isn't,
it ain't. That's logic" -- Lewis Carroll



Nov 16 '05 #8
Einar,
As David suggests: For information & ideas on exception handling in Add-Ins
see:

http://msdn.microsoft.com/msdnmag/is...10/Plug%2Dins/

Hope this helps
Jay
"Einar Høst" <_e*******@hotm ail.com> wrote in message
news:e%******** ********@TK2MSF TNGP09.phx.gbl. ..
Hi Jay,

Thanks for the input and the pointer to the article. I think I may have read it a while ago, but I believe it's worth another look.

There are many issues related to exception handling (obviously), but
handling unhandled exceptions is actually very important to us, as we're
writing an add-in to an existing program. We don't want to bring everything else down with us... I think the rest of the guys I'm working with should
read the article too.

Thanks again.

Einar

"Jay B. Harlow [MVP - Outlook]" <Ja************ @msn.com> wrote in message
news:eW******** ******@tk2msftn gp13.phx.gbl...
Einar,
In addition to the other comments about using the Exception Management
Block, I normally do my logging in a global exception handler. (Read I may
use the Exception Management Block in my Global Exception Handler)

Also I use try/finally & using more then I use try/catch. I only use
try/catch when there is something specific that I need to do with the
exception, otherwise I let my global exception handlers handle the
exception.

Depending on the type of application you are creating, .NET has three
different global exception handlers.

For ASP.NET look at:
System.Web.Http Application.Err or event
Normally placed in your Global.asax file.

For console applications look at:
System.AppDomai n.UnhandledExce ption event
Use AddHandler in your Sub Main.

For Windows Forms look at:
System.Windows. Forms.Applicati on.ThreadExcept ion event
Use AddHandler in your Sub Main.

It can be beneficial to combine the above global handlers in your app, as well as wrap your Sub Main in a try catch itself.

There is an article in the June 2004 MSDN Magazine that shows how to
implement the global exception handling in .NET that explains why & when

you
use multiple of the above handlers...

http://msdn.microsoft.com/msdnmag/is...T/default.aspx

For example: In my Windows Forms apps I would have a handler attached to

the
Application.Thr eadException event, plus a Try/Catch in my Main. The
Try/Catch in Main only catches exceptions if the constructor of the

MainForm
raises an exception, the Application.Thr eadException handler will catch

all
uncaught exceptions from any form/control event handlers.

Hope this helps
Jay
"Einar Høst" <_e*******@hotm ail.com> wrote in message
news:uw******** ******@tk2msftn gp13.phx.gbl...
Hi,

I'm getting into the Trace-functionality in .NET, using it to provide

some much-needed logging across dlls in the project we're working on. However, being a newbie, I'm wondering if some more experienced loggers can provide me with some ideas as to how to log in a simple yet flexible manner. For instance, I'd like the code to be as uncluttered as possible by Trace
statements.

As an example of basic logging functionality, I've come up with some
alternatives for logging exceptions that occur in an object:

1) Wrap the throwing of an exception in a method, which can handle any
logging before throwing the actual exception.

2) Handle logging in the constructors of my own hierarchy of exceptions. This makes the logging more transparent in the code, but doesn't work for standard .NET exceptions such as ArgumentNullExc eption (I'd have to

subtype
it).

3) Use a decorator object to wrap the original object, catch all

exceptions,
write to log, and rethrow.

Any and all thoughts/comments are much appreciated!

Regards,
Einar

--
"If it was so, it might be; and if it were so, it would be; but as it

isn't,
it ain't. That's logic" -- Lewis Carroll



Nov 16 '05 #9
Hi David,

Thanks for the input. I'm learning a lot from this.

I agree with your reasoning; however, since there are several developers on
my project, there is no way I can guarantee that the guidelines you're
outlining will actually be followed. I'm not even sure if I can trust myself
all the time. I'm trying to do things the right way, though.

So basically I'm thinking I need to include a UE handler as a last resort,
in order enable some logging that might point in the direction of the weak
code. The reason I'm looking into these things a bit more seriously is that
I've become annoyed with the add-in dying (and taking the main app with it)
with little or no information saying why.

Thanks again,
Einar.
"David Levine" <no************ ****@wi.rr.com> wrote in message
news:OW******** *****@TK2MSFTNG P11.phx.gbl...
If you want to avoid bringing everything else down then you cannot allow the exception to be unhandled, especially if you are writing an add-in. You
should wrap all threads that you create in try-catch blocks.

The rules under v1.0 and v1.1 of the runtime are that if the unhandled
exception occurs on the main thread or a thread that originates in unmanaged code the application will be terminated. You cannot change this - it is
baked into the runtime.

If the unhandled exception occurs on a thread other then this, such as a
threadpool thread, one manually started, or the finalizer thread, then an
unhandled exception event will be sent and the exception will be swallowed. While the current implementation of the runtime does not terminate an app on these threads there is no guarantee that this will not change, and in fact
it probably will (and should) change.

There is a flag in the event args that indicates if the app will exit - this is a readonly indicator of what will happen to the app after the UE handler has run to completion.

I also disagree conceptually with using the UE handler as the backstop
exception handler. It is convenient to use it that way but I consider it to be bad practice - I prefer to wrap all threads, etc. in a try-catch, also
using specific try-catches as necessary to locally recover from errors, and I treat all UEs as a indication that a programming error may have occurred. I definitely log all that I get but I consider them to be bugs.

I agree with the liberal use of try-finally blocks.

regards,
Dave
"Einar Høst" <_e*******@hotm ail.com> wrote in message
news:e%******** ********@TK2MSF TNGP09.phx.gbl. ..
Hi Jay,

Thanks for the input and the pointer to the article. I think I may have

read
it a while ago, but I believe it's worth another look.

There are many issues related to exception handling (obviously), but
handling unhandled exceptions is actually very important to us, as we're
writing an add-in to an existing program. We don't want to bring

everything
else down with us... I think the rest of the guys I'm working with should
read the article too.

Thanks again.

Einar

"Jay B. Harlow [MVP - Outlook]" <Ja************ @msn.com> wrote in message news:eW******** ******@tk2msftn gp13.phx.gbl...
Einar,
In addition to the other comments about using the Exception Management
Block, I normally do my logging in a global exception handler. (Read I may use the Exception Management Block in my Global Exception Handler)

Also I use try/finally & using more then I use try/catch. I only use
try/catch when there is something specific that I need to do with the
exception, otherwise I let my global exception handlers handle the
exception.

Depending on the type of application you are creating, .NET has three
different global exception handlers.

For ASP.NET look at:
System.Web.Http Application.Err or event
Normally placed in your Global.asax file.

For console applications look at:
System.AppDomai n.UnhandledExce ption event
Use AddHandler in your Sub Main.

For Windows Forms look at:
System.Windows. Forms.Applicati on.ThreadExcept ion event
Use AddHandler in your Sub Main.

It can be beneficial to combine the above global handlers in your app, as well as wrap your Sub Main in a try catch itself.

There is an article in the June 2004 MSDN Magazine that shows how to
implement the global exception handling in .NET that explains why & when you
use multiple of the above handlers...

http://msdn.microsoft.com/msdnmag/is...T/default.aspx

For example: In my Windows Forms apps I would have a handler attached
to
the
Application.Thr eadException event, plus a Try/Catch in my Main. The
Try/Catch in Main only catches exceptions if the constructor of the

MainForm
raises an exception, the Application.Thr eadException handler will
catch all
uncaught exceptions from any form/control event handlers.

Hope this helps
Jay
"Einar Høst" <_e*******@hotm ail.com> wrote in message
news:uw******** ******@tk2msftn gp13.phx.gbl...
> Hi,
>
> I'm getting into the Trace-functionality in .NET, using it to
provide some
> much-needed logging across dlls in the project we're working on.

However,
> being a newbie, I'm wondering if some more experienced loggers can

provide
> me with some ideas as to how to log in a simple yet flexible manner. For > instance, I'd like the code to be as uncluttered as possible by
Trace > statements.
>
> As an example of basic logging functionality, I've come up with some
> alternatives for logging exceptions that occur in an object:
>
> 1) Wrap the throwing of an exception in a method, which can handle any > logging before throwing the actual exception.
>
> 2) Handle logging in the constructors of my own hierarchy of

exceptions. > This makes the logging more transparent in the code, but doesn't work for
> standard .NET exceptions such as ArgumentNullExc eption (I'd have to
subtype
> it).
>
> 3) Use a decorator object to wrap the original object, catch all
exceptions,
> write to log, and rethrow.
>
> Any and all thoughts/comments are much appreciated!
>
> Regards,
> Einar
>
> --
> "If it was so, it might be; and if it were so, it would be; but as

it isn't,
> it ain't. That's logic" -- Lewis Carroll
>
>



Nov 16 '05 #10

This thread has been closed and replies have been disabled. Please start a new discussion.

Similar topics

0
1215
by: Jeremy Fincher | last post by:
I've just converted my application to use the logging module for its logging needs (it's quite excellent, actually :)). One thing I still have to resolve, though: in many places in my application, I want to catch *all* exceptions *except*, for instance, KeyboardInterrupt and SystemExit. So I'll have code like this: try: callback(data) except Exception, e: log.exception("Uncaught exception from callback")
6
9966
by: Kevin Jackson | last post by:
Let's say we log exceptions to the windows application event log using the Exception Management Application Block. Is there a pattern that can be used so the exception is logged only once and not everytime up through the call chain? Is there anything a caller can key off of to check to see if it should also log the exception?
6
1993
by: Ali-R | last post by:
I'm using a .Net application to execute DTS packages within Sqlserver,I need to have very customizable and powerful Exception maangement systems which loggs different issues happend in the DTS package with my own errorCode. Can somebody give me some ideas? Thanks
1
319
by: BobLaughland | last post by:
Hi All, I am development an ASP .NET C# web site. Just wondering the best way to implement logging on my web site. (I have a logging class to log database access, exceptions, etc, etc). I have about 10 pages in my web site (that is 10 seperate c# files with code), and 4 separate classes in the App_Code directory.
17
2745
by: Cramer | last post by:
I plan to implement an exception logging feature in an ASP.NET Web application that writes encountered exceptions to disk. The exception data will be stored as XML. I am planning on having each exception written to its own XML file. I plan to NOT append exceptions to a single XML file because I don't want for the exception logging component to have to deal with contention for access to the file. This is possible when, for example,...
4
3396
by: Alexandru Mosoi | last post by:
why doesn't logging throw any exception when it should? how do I configure logging to throw exceptions? .... logging.fatal('asdf %d', '123') .... except: .... print 'this line is never printed' .... Traceback (most recent call last): File "/Library/Frameworks/Python.framework/Versions/2.5/lib/ python2.5/logging/__init__.py", line 744, in emit
0
8703
marktang
by: marktang | last post by:
ONU (Optical Network Unit) is one of the key components for providing high-speed Internet services. Its primary function is to act as an endpoint device located at the user's premises. However, people are often confused as to whether an ONU can Work As a Router. In this blog post, we’ll explore What is ONU, What Is Router, ONU & Router’s main usage, and What is the difference between ONU and Router. Let’s take a closer look ! Part I. Meaning of...
0
8623
by: Hystou | last post by:
Most computers default to English, but sometimes we require a different language, especially when relocating. Forgot to request a specific language before your computer shipped? No problem! You can effortlessly switch the default language on Windows 10 without reinstalling. I'll walk you through it. First, let's disable language synchronization. With a Microsoft account, language settings sync across devices. To prevent any complications,...
0
9185
Oralloy
by: Oralloy | last post by:
Hello folks, I am unable to find appropriate documentation on the type promotion of bit-fields when using the generalised comparison operator "<=>". The problem is that using the GNU compilers, it seems that the internal comparison operator "<=>" tries to promote arguments from unsigned to signed. This is as boiled down as I can make it. Here is my compilation command: g++-12 -std=c++20 -Wnarrowing bit_field.cpp Here is the code in...
0
9050
jinu1996
by: jinu1996 | last post by:
In today's digital age, having a compelling online presence is paramount for businesses aiming to thrive in a competitive landscape. At the heart of this digital strategy lies an intricately woven tapestry of website design and digital marketing. It's not merely about having a website; it's about crafting an immersive digital experience that captivates audiences and drives business growth. The Art of Business Website Design Your website is...
0
8893
tracyyun
by: tracyyun | last post by:
Dear forum friends, With the development of smart home technology, a variety of wireless communication protocols have appeared on the market, such as Zigbee, Z-Wave, Wi-Fi, Bluetooth, etc. Each protocol has its own unique characteristics and advantages, but as a user who is planning to build a smart home system, I am a bit confused by the choice of these technologies. I'm particularly interested in Zigbee because I've heard it does some...
0
7773
agi2029
by: agi2029 | last post by:
Let's talk about the concept of autonomous AI software engineers and no-code agents. These AIs are designed to manage the entire lifecycle of a software development project—planning, coding, testing, and deployment—without human intervention. Imagine an AI that can take a project description, break it down, write the code, debug it, and then launch it, all on its own.... Now, this would greatly impact the work of software developers. The idea...
1
6540
isladogs
by: isladogs | last post by:
The next Access Europe User Group meeting will be on Wednesday 1 May 2024 starting at 18:00 UK time (6PM UTC+1) and finishing by 19:30 (7.30PM). In this session, we are pleased to welcome a new presenter, Adolph Dupré who will be discussing some powerful techniques for using class modules. He will explain when you may want to use classes instead of User Defined Types (UDT). For example, to manage the data in unbound forms. Adolph will...
0
4389
by: TSSRALBI | last post by:
Hello I'm a network technician in training and I need your help. I am currently learning how to create and manage the different types of VPNs and I have a question about LAN-to-LAN VPNs. The last exercise I practiced was to create a LAN-to-LAN VPN between two Pfsense firewalls, by using IPSEC protocols. I succeeded, with both firewalls in the same network. But I'm wondering if it's possible to do the same thing, with 2 Pfsense firewalls...
2
2359
muto222
by: muto222 | last post by:
How can i add a mobile payment intergratation into php mysql website.

By using Bytes.com and it's services, you agree to our Privacy Policy and Terms of Use.

To disable or enable advertisements and analytics tracking please visit the manage ads & tracking page.