Take the 2-minute tour ×
Programmers Stack Exchange is a question and answer site for professional programmers interested in conceptual questions about software development. It's 100% free, no registration required.

I am currently working on creating a toolkit for work and I've gotten to the point where I'm wondering about error reporting.

Basically all of my tools, which consist of a grouping of classes, will eventually be ran from a main method. Many of these tools will be doing operations on file like reading them in and converting them into some sort of array of objects or writing an object array to a file in a certain format. Whenever you are dealing with data that your program didn't create there is always room for error and those errors need to be known.

With that said what would be a good method to document all of the errors that occur during the processing and allow them to be retrieved later? Considering that I may want to send these error information out later I don't think that Log4J would be a good fit. I was considering using a string builder in each of my processing classes and append all error to that builder and retrieve it later at my leisure. I was also thinking of using some sort of arrayList or something that would hold the different types of errors but I'm a bit at a loss.

Does anyone have any good methods of doing this?

share|improve this question
add comment

migrated from stackoverflow.com May 16 '13 at 13:35

This question came from our site for professional and enthusiast programmers.

1 Answer

up vote 1 down vote accepted

It sounds like you are trying to enable remote logging. Log4J is a fine fit for this. What you can do in the most basic way possible is open up a socket that sends data to a message queue. This message queue will have a listener attached to it that can handle the different log messages it receives. This data can later be persisted into a database which you can than query against to generate reports.

Using StringBuilder makes very little to no sense, because it sounds like you are trying to just consume a bunch of space on the host system.

FROM THE COMMENTS

Correct, once these errors are fixed I no longer need them. Is it standard practice to funnel all errors from applications into a single database? I don't mind keeping the data if this is the correct method of doing so however only the newest information will be looked at

It is more a standard practice to keep a dedicated audit log, depending on your policy / legal requirements this can be anywhere from 90 days to 2 years. This enables you to go back and prove that steps were taken to mitigate compliance issues, track down malicious activity, etc. While it is true that logs are only good for a limited period of time, it is greatly beneficial to see audit logs when you are trying to track down a recurring issue in the system.

share|improve this answer
    
Considering that the error data is only useful until the next run would it still be wise to store it in a database? I could remove the old data but that seems like extra work. –  David Wallace May 14 '13 at 19:15
    
@DavidWallace so you want to completely lose an audit trail? –  Woot4Moo May 14 '13 at 19:16
    
Correct, once these errors are fixed I no longer need them. Is it standard practice to funnel all errors from applications into a single database? I don't mind keeping the data if this is the correct method of doing so however only the newest information will be looked at. –  David Wallace May 14 '13 at 19:21
    
@DavidWallace edited my answer. –  Woot4Moo May 14 '13 at 19:23
    
@DavidWallace cat ~/Library/Logs/** /var/log/** /Library/Logs/** | xz | wc -c tells me all the logs produced on my system since whenever I bothered to nuke them compress down into 5MB. The user can live with whatever you produce. And standard practice is to funnel them into logs and inspect those whenever necessary, but if you're trying to roll your own integrated error reporting solution you're obviously not in a standard situation. –  millimoose May 14 '13 at 19:29
show 1 more comment

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.