THIS IS A TEST INSTANCE. ALL YOUR CHANGES WILL BE LOST!!!!
Overview
This provides some convenience methods to make it easier to do programmer level logging.
This provides information useful for debugging and error remediation by a programmer.
.
Design Goals
- It should support globalization so that the logs are in the language that the application developers/maintainers want to read
- It should facilitate the use of Error Numbers organized into a developer specified category structure "ACC-1024 - accounting error 1024" "MAN-1024 - manufacturing error 1024.
- Thread-safe.
Basic Architecture
Uses SLF4J to create log files.
Additional Loggig Functions
There is also a need for support for Audit Trails and User Error Logs.
Audit Trail support makes it easier for application developers to provide information about tasks completed and entities affected.
Error Logs provide non-technical managers with explanations of errors detected during operations that may or may not have any UI interaction.
These can be caused by batch process, interaction with external systems and any situation where the information required to fix a problem is beyond the scope of the end-user.
The Error Log can provide a plain language statement of the cause of the error. It is different from the programmer log as it is meant to be read by a person who knows the application area but not the structure of the program.
Configuration errors, gateway failures, bulk data errors and data integrity issues are examples of where the Error Log can help the administrator(s) of the application make the corrective actions or dispatch the problem to the appropriate tecnical people.
4 Comments
Jacques Le Roux
I wonder about "Error Numbers". I experienced a such thing in a custom project (OFBiz based of course) and it eventually ended with a lot of work which was not really used.
Ron Wheeler
What were the pros and cons that you saw?
I am hoping that it will enforce a certain amount of consistency and make it easier to translate and document errors and provide troubleshhoting advice for each error type rather than for each error instance.
Was your project team very large where consistency could be an issue or small where it is easy (or at least easier) to keep the team working together?
I was influenced by the ORACLE DB which has used error numbers since the begnning in the 1980's.
It is perhaps better to return a context sensitive code and description to a user than to allow an Exception to trickle up to the user.
Use of Error codes in the Error Log does not preclude logging of the description and capturing of stack traces in the Programmer's Log..
http://programmers.stackexchange.com/questions/98034/how-do-you-assign-error-codes
Jacques Le Roux
I think you answered yourself with the link above
Jacques Le Roux
More seriously and to answer your question:
The team was middle sized (an average of 10 persons) for this relatively big OFBiz based project (2,5 years) for a challenging European client (in IT business). The main goal for these codes was statistical. They were supposed to be used to follow the errors and their importance in term of recurrence, etc. So the error codes were saved in the OFBiz DB. But they were never used for any purpose, kinda waste of time if you want my opinion (XP YAGNI principle not applied)
It's my turn to ask a question, for what would you want to have error codes in OFBiz?