Is it safe to store exception objects?
I am creating a test logger that will contain information about all the exceptions that are thrown so that they can be displayed correctly using the GUI.
Can the following construction be used:
public class TestLogEntry {
public System.Exception Exception { get; private set; }
public TestLogEntry(/*...,*/ System.Exception exception = null) {
//...
Exception = exception;
}
}
Or will it be better?
public class TestLogEntry {
public string StackTrace { get; private set; }
public System.Type ExceptionType { get; private set; }
public string ExceptionMessage { get; private set; }
public TestLogEntry(/*...,*/ System.Exception exception = null) {
//...
if (exception != null) {
StackTrace = exception.StackTrace;
ExceptionType = exception.GetType();
ExceptionMessage = exception.Message;
}
}
}
While the first approach is more flexible (since it can contain additional user data), here are my problems:
- Saving the exception object for a long period.
- Using large amounts of memory if exception objects prevent LOB collection.
- An exception returning invalid values when accessed from context.
Q1. Are the above problems valid?
Q2. Do exception objects usually refer to many other data?
source to share
Your problems are valid: exception objects can take place for any other object. This is very rare in practice. I have never actually seen the property Exception.Data
. But I saw that the derived class Exception
holds something big with custom fields: WebException
has a property WebResponse
!
So, you see that you can support life even for something expensive, like an unmanaged resource.
I would copy the information and discard Exception
. Don't forget to copy as well InnerException
.
Another concern might be what Exception
is mutable type . You can throw it at any time by changing the stack trace. I would like to capture his state for this very reason.
Memory usage is also important . The exception has some fields that are probably never used. You can save them. In addition, nesting your fields in a log message object will result in the exception of the object header and object reference. Small win, but might be worth accepting in case of frequent exceptions.
source to share
Keeping exceptions in order.
In general, they don't contain a lot of data (stack trace, error message, and related data), but they don't have much.
And one instance of the exception will not affect other instances of even the same type.
So:
Saving the exception object for a long period.
No problems.
Using large amounts of memory if exception objects prevent LOB collection.
Only problem if you add a lot of data to your exceptions - if you don't, it is not a problem.
An exception returning invalid values when accessed from context.
Not sure what that means - what's the context? The exception is the exception.
source to share
I think you should understand that when you write "protracted" or "a lot", they are more relative than absolute, so no one can tell if these problems are too much or not. I have 2GB of RAM on my 10-core machine and I am deploying Windows servers, so the memory implications don't bother me in the least. You may be running an old Windows phone with a few bytes of spare RAM. Who knows? If in doubt please comment on your memory usage, but I would be surprised if there is a memory issue.
All in all, a big concern for me would be that you might be tempted to use Exceptions as a way to display status messages to the user, which isn't very cool. Exceptions for exceptional conditions. You might not even be able to recover from them meaningfully, let alone continue as usual. Exceptions can be written to the database (using log4net for example) if you want to keep their records, but I think you are better off logging them rather than saving them.
source to share