The current system I am working on goes through a set of documents & performs some logic using the metadata of the document. If the metadata of a document is fishy..it throws an exception. The system logs the exception, fail the job & let the developer fix the issue by looking at logs before moving on.
I want to improvise this system by making system fault tolerant as I have seen that generally the job fails because of few documents. System continues even if there’s an exception raised. The exception information would be stored in the database table along with document information. This information would be sent to developer who can then work on fixing it without having customer waiting. The customer can later process those failed documents separately.
My question is how to store the exception information in table. The exception would already be logged in the log file. One idea I was thinking was to store the time stamp of the exception so that developer can later find the time stamp in log file and understand the exception. But this comes with a possibility that the log files might be deleted.
Does it make sense to store the entire stack trace in the database?
To answer your question, you need to answer this:
Does the stack trace provide useful, additional diagnostic information that the exception itself doesn’t have?
If yes, then sure, go ahead and store the stack trace information.
If no, then don’t waste your time.
As to how to store the stack trace, there’s all sorts of methods that you can consider. For example, it’s fairly trivial to create a routine that converts the stack information into strings and then store those strings. Likewise, you could pull whatever additional arguments are on the stack and push those into the strings that you’re creating. It all depends upon what information you need.
More broadly, you should log information that helps you diagnose and resolve issues. Whether you store that in a log file or a database is somewhat immaterial. The point is that you’re trying to record the error information when the error occurs.
If you’re worried that the error information won’t persist with whatever mechanism you chose (aka your logfile got deleted) then you need to come up with a more robust persistence mechanism for the error information. But that problem is a separate issue from whether or not you should log XYZ information about an error.
1
Yes. Storage is cheap.
It probably won’t be accessed much (verify) or see a large number of records (verify as well).
One possible concern would be security, if access to the DB isn’t as well protected as access to the log: can someone get undesired access to the traces, and from them obtain information that helps them compromise something else?