Exception throw

[Nenad Dobrilovic]

Hi,
Is it possible for exception object to be aware of it's throwing?
I want to log in the text file when exeption is thrown, not when the
exception object is created (because I can create exception object that
is never thrown).
Thank you,
Nenad

[Marcin Grzębski]

Hi

Hi,
Is it possible for exception object to be aware of it's throwing?
I want to log in the text file when exeption is thrown, not when the
exception object is created (because I can create exception object that
is never thrown).
Thank you,
Nenad

I think that there is no reason to create Exception object if it
will not be thrown. But i don't want to settle "my own" coding
standards.

If you want to log exception's throw, so there is no better
place to log it than the last (or first) catch of this exception.

use:

try {
// YourException danger
}
catch(YourException ex) {
// place for logging to text file
throw;
}

Regards

Marcin

[David Levine]

There currently is no means for the exception object itself to detect when
it is thrown, but it is easy for your code to explicitly log it when it
throws the exception. What are you trying to accomplish?
"Nenad Dobrilovic" <ch*******@hotmail.com> wrote in message
news:uh**************@TK2MSFTNGP09.phx.gbl...

Hi,
Is it possible for exception object to be aware of it's throwing?
I want to log in the text file when exeption is thrown, not when the
exception object is created (because I can create exception object that
is never thrown).
Thank you,
Nenad

[Leon Lambert]

Most people create their own application exceptions instead of using the
generic System.Exception so i will assume you did also. What you could
do is create a Factory method on you exception class and have it create
the exception, log to somewhere then throw the exception. Following is a
short example.
class MyException : Exception{
public MyException(String msg) : base(msg){
}
public static void ExceptionFactory(String msg){
MyException except = new MyException(msg);
// log it
System.Console.Out.WriteLine(msg);
throw(except);
}
}

call it like this.
MyException.ExceptionFactory("Test Exception");
Just an idea hope it helps.
Leon Lambert

Nenad Dobrilovic wrote:

Hi,
Is it possible for exception object to be aware of it's throwing?
I want to log in the text file when exeption is thrown, not when the
exception object is created (because I can create exception object that
is never thrown).
Thank you,
Nenad

[Nenad Dobrilovic]

Leon Lambert wrote:

Most people create their own application exceptions instead of using the
generic System.Exception so i will assume you did also. What you could
do is create a Factory method on you exception class and have it create
the exception, log to somewhere then throw the exception. Following is a
short example.
class MyException : Exception{
public MyException(String msg) : base(msg){
}
public static void ExceptionFactory(String msg){
MyException except = new MyException(msg);
// log it
System.Console.Out.WriteLine(msg);
throw(except);
}
}

call it like this.
MyException.ExceptionFactory("Test Exception");
Just an idea hope it helps.
Leon Lambert

Nenad Dobrilovic wrote:

Hi,
Is it possible for exception object to be aware of it's throwing?
I want to log in the text file when exeption is thrown, not when the
exception object is created (because I can create exception object
that is never thrown).
Thank you,
Nenad

Thank you,

OK, I did it the same way you told me, but just before I read it :)
I think it is goog idea.

Nenad

[Nenad Dobrilovic]

David Levine wrote:

There currently is no means for the exception object itself to detect when
it is thrown, but it is easy for your code to explicitly log it when it
throws the exception. What are you trying to accomplish?
"Nenad Dobrilovic" <ch*******@hotmail.com> wrote in message
news:uh**************@TK2MSFTNGP09.phx.gbl...

Hi,
Is it possible for exception object to be aware of it's throwing?
I want to log in the text file when exeption is thrown, not when the
exception object is created (because I can create exception object that
is never thrown).
Thank you,
Nenad

I want that when someone write:
throw new LoggedException(...);
it is automatically logged in text file.

[Nenad Dobrilovic]

Marcin Grzębski wrote:

Hi

Hi,
Is it possible for exception object to be aware of it's throwing?
I want to log in the text file when exeption is thrown, not when the
exception object is created (because I can create exception object
that is never thrown).
Thank you,
Nenad

I think that there is no reason to create Exception object if it
will not be thrown. But i don't want to settle "my own" coding
standards.

If you want to log exception's throw, so there is no better
place to log it than the last (or first) catch of this exception.

use:

try {
// YourException danger
}
catch(YourException ex) {
// place for logging to text file
throw;
}

Regards

Marcin

I have class with some public methods. Methods can throw exceptions, but
I want that user-class can define which exception must be thrown.
Example:
public class One
{
public void oneFun(Exception e)
{
...
throw e; <- WRITING IN LOG FILE
}
}

public class Two
{
public void twoFun()
{
...
One one = new One();
one.oneFun(new LoggedException()); <- NOT WRITING IN LOG FILE
...
}
}

[Nicholas Paldino [.NET/C# MVP]]

Nenad,

I think that what you are doing is a bad idea. There are two reasons
for this. The first is that it is completely possible that your exceptions
can be caught and handled inside the application boundaries, which
eliminates the exceptional case. In this case, you would have entries in
the log that would be frivilous. The second is that other exceptions that
are not handled inside the application will not log.

If the case that you want to just log items, you should really use
something else other than an exception (unless you truly have an exceptional
condition). Throwing exceptions can have a detrimental effect on
performance.

If anything, I would say have exception handlers that exist at the app
domain boundaries, and then have a general logging mechanism for ANY
exception that is caught during program execution. If you want to log other
events outside of exception handling, then have a general log library to do
that.

Hope this helps.
--
- Nicholas Paldino [.NET/C# MVP]
- mv*@spam.guard.caspershouse.com

"Nenad Dobrilovic" <ch*******@hotmail.com> wrote in message
news:Oi**************@TK2MSFTNGP12.phx.gbl...

Leon Lambert wrote:

Most people create their own application exceptions instead of using the
generic System.Exception so i will assume you did also. What you could
do is create a Factory method on you exception class and have it create
the exception, log to somewhere then throw the exception. Following is a
short example.
class MyException : Exception{
public MyException(String msg) : base(msg){
}
public static void ExceptionFactory(String msg){
MyException except = new MyException(msg);
// log it
System.Console.Out.WriteLine(msg);
throw(except);
}
}

call it like this.
MyException.ExceptionFactory("Test Exception");
Just an idea hope it helps.
Leon Lambert

Nenad Dobrilovic wrote:

Hi,
Is it possible for exception object to be aware of it's throwing?
I want to log in the text file when exeption is thrown, not when the
exception object is created (because I can create exception object
that is never thrown).
Thank you,
Nenad

Thank you,

OK, I did it the same way you told me, but just before I read it :)
I think it is goog idea.

Nenad

[Nenad Dobrilovic]

Nicholas Paldino [.NET/C# MVP] wrote:

Nenad,

I think that what you are doing is a bad idea. There are two reasons
for this. The first is that it is completely possible that your exceptions
can be caught and handled inside the application boundaries, which
eliminates the exceptional case. In this case, you would have entries in
the log that would be frivilous. The second is that other exceptions that
are not handled inside the application will not log.

If the case that you want to just log items, you should really use
something else other than an exception (unless you truly have an exceptional
condition). Throwing exceptions can have a detrimental effect on
performance.

If anything, I would say have exception handlers that exist at the app
domain boundaries, and then have a general logging mechanism for ANY
exception that is caught during program execution. If you want to log other
events outside of exception handling, then have a general log library to do
that.

Hope this helps.

Thank you,
My idea was to have exception which is logged (in file) every time when
it is thrown, without any other actions.
If one has to log exception every time he catch it, it is possible for
him to forget to log it. Beside, it is the same code in every catch()
block, so it is dull and tiresome.

[Nicholas Paldino [.NET/C# MVP]]

Nenad,

The thing is, why are you logging every exception that is thrown? It's
the exceptions that are not caught that are the issue, IMO. If the
exception is caught and handled later on in your application, then what's
the point of knowing that it was even thrown at all?

This is why you have one exception handler at the entry point to your
app that will do the logging. That way, you have access to ALL unhandled
exceptions, not just your kind (and they are unhandled, which is really the
more problematic of the situations).
--
- Nicholas Paldino [.NET/C# MVP]
- mv*@spam.guard.caspershouse.com

"Nenad Dobrilovic" <ch*******@hotmail.com> wrote in message
news:eN**************@tk2msftngp13.phx.gbl...

Nicholas Paldino [.NET/C# MVP] wrote:

Nenad,

I think that what you are doing is a bad idea. There are two reasons for this. The first is that it is completely possible that your exceptions can be caught and handled inside the application boundaries, which
eliminates the exceptional case. In this case, you would have entries in the log that would be frivilous. The second is that other exceptions that are not handled inside the application will not log.

If the case that you want to just log items, you should really use
something else other than an exception (unless you truly have an exceptional condition). Throwing exceptions can have a detrimental effect on
performance.

If anything, I would say have exception handlers that exist at the app domain boundaries, and then have a general logging mechanism for ANY
exception that is caught during program execution. If you want to log other events outside of exception handling, then have a general log library to do that.

Hope this helps.

Thank you,
My idea was to have exception which is logged (in file) every time when
it is thrown, without any other actions.
If one has to log exception every time he catch it, it is possible for
him to forget to log it. Beside, it is the same code in every catch()
block, so it is dull and tiresome.

[Nenad Dobrilovic]

Nicholas Paldino [.NET/C# MVP] wrote:

Nenad,

The thing is, why are you logging every exception that is thrown? It's
the exceptions that are not caught that are the issue, IMO. If the
exception is caught and handled later on in your application, then what's
the point of knowing that it was even thrown at all?

This is why you have one exception handler at the entry point to your
app that will do the logging. That way, you have access to ALL unhandled
exceptions, not just your kind (and they are unhandled, which is really the
more problematic of the situations).

OK, I agree. I do not log every exception that is thrown.
I have to log every throwning of some kind of exception (I called it
LoggedException), no metter if it is handled or not.
I want to overview log file later, so I can see when did my app
recovered (or not) of serious error (what was wrong, etc.)

[Nicholas Paldino [.NET/C# MVP]]

Nenad,

If that is the case, the best thing you can do is write to the log when
the exception is created. The reason for this is that there is no hook in
the framework to allow you to know when an exception is thrown. Since most
people do not keep instances of exceptions hanging around in their code, I
think it is safe to log when the constructor is thrown.

--
- Nicholas Paldino [.NET/C# MVP]
- mv*@spam.guard.caspershouse.com

"Nenad Dobrilovic" <ch*******@hotmail.com> wrote in message
news:el**************@TK2MSFTNGP10.phx.gbl...

Nicholas Paldino [.NET/C# MVP] wrote:

Nenad,

The thing is, why are you logging every exception that is thrown? It's the exceptions that are not caught that are the issue, IMO. If the
exception is caught and handled later on in your application, then what's the point of knowing that it was even thrown at all?

This is why you have one exception handler at the entry point to your app that will do the logging. That way, you have access to ALL unhandled exceptions, not just your kind (and they are unhandled, which is really the more problematic of the situations).

OK, I agree. I do not log every exception that is thrown.
I have to log every throwning of some kind of exception (I called it
LoggedException), no metter if it is handled or not.
I want to overview log file later, so I can see when did my app
recovered (or not) of serious error (what was wrong, etc.)

[Nenad Dobrilovic]

Nicholas Paldino [.NET/C# MVP] wrote:

Nenad,

If that is the case, the best thing you can do is write to the log when
the exception is created. The reason for this is that there is no hook in
the framework to allow you to know when an exception is thrown. Since most
people do not keep instances of exceptions hanging around in their code, I
think it is safe to log when the constructor is thrown.

Yes, I did just like that in the first place.
But, sometimes I create exception object without throwing it.

Example:

public class LoggedException : Exception
{
LoggedException()
{
log();
}
}

public class One
{
public void oneFun(Exception e)
{
...
if (..)
throw e; <- WRITE IN LOG FILE!
...
}
}

public class Two
{
public void twoFun()
{
...
One one = new One();
one.oneFun(new LoggedException()); <- I DONT WANT TO LOG THIS!
...
}
}

So, I had a lot of lines in log which is not actually errors... That is
when my drinking problems begun...

[Jay B. Harlow [MVP - Outlook]]

Nenad,
In addition to the other comments:

My idea was to have exception which is logged (in file) every time when
it is thrown, without any other actions.
If one has to log exception every time he catch it, it is possible for
him to forget to log it. Beside, it is the same code in every catch()
block, so it is dull and tiresome.
Depending on the type of application you are creating, .NET has three
different global exception handlers.

For ASP.NET look at:
System.Web.HttpApplication.Error event
Normally placed in your Global.asax file.

For console applications look at:
System.AppDomain.UnhandledException event
Use AddHandler in your Sub Main.

For Windows Forms look at:
System.Windows.Forms.Application.ThreadException 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.ThreadException 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.ThreadException handler will catch all
uncaught exceptions from any form/control event handlers.

Hope this helps
Jay
"Nenad Dobrilovic" <ch*******@hotmail.com> wrote in message
news:eN**************@tk2msftngp13.phx.gbl... Nicholas Paldino [.NET/C# MVP] wrote:

Nenad,

I think that what you are doing is a bad idea. There are two reasons for this. The first is that it is completely possible that your exceptions can be caught and handled inside the application boundaries, which
eliminates the exceptional case. In this case, you would have entries in the log that would be frivilous. The second is that other exceptions that are not handled inside the application will not log.

If the case that you want to just log items, you should really use
something else other than an exception (unless you truly have an exceptional condition). Throwing exceptions can have a detrimental effect on
performance.

If anything, I would say have exception handlers that exist at the app domain boundaries, and then have a general logging mechanism for ANY
exception that is caught during program execution. If you want to log other events outside of exception handling, then have a general log library to do that.

Hope this helps.

Thank you,
My idea was to have exception which is logged (in file) every time when
it is thrown, without any other actions.
If one has to log exception every time he catch it, it is possible for
him to forget to log it. Beside, it is the same code in every catch()
block, so it is dull and tiresome.

[David Levine]

If the exception is a custom exception that you define then you can call the
logging code from within the constructor of the exception. Other than that
(leaving aside future mechanisms like AOP) you are out of luck.

"Nenad Dobrilovic" <ch*******@hotmail.com> wrote in message
news:Oq*************@TK2MSFTNGP09.phx.gbl...

David Levine wrote:

There currently is no means for the exception object itself to detect when it is thrown, but it is easy for your code to explicitly log it when it
throws the exception. What are you trying to accomplish?
"Nenad Dobrilovic" <ch*******@hotmail.com> wrote in message
news:uh**************@TK2MSFTNGP09.phx.gbl...

Hi,
Is it possible for exception object to be aware of it's throwing?
I want to log in the text file when exeption is thrown, not when the
exception object is created (because I can create exception object that
is never thrown).
Thank you,
Nenad

I want that when someone write:
throw new LoggedException(...);
it is automatically logged in text file.