Writing an error handler package

Question

I want to standardize on an error handling package, with a record type declared that is anchored to a table. Some obvious attributes I can think of for the table are the following:
1. Time stamp
2. The package that threw the error
3. The method that threw the error
4. Any textual content written by the programmer that invoked the package. Perhaps that could be a concatenation of relevant fields with a delimiter for example.
5. The severity of the error. For example, it could be 'fatal' i.e. can't move any more, 'severe' i.e. threw out junk but leaves the result table with too little content to be practical etc.
6. The author who wrote the code.
My questions are:
(i) In the experience of seasoned writers of libraries in this forum, are there other significant fields (and enumerated values of error types) that you capture, independent of the domain that you are writing this for?
(ii) Is there an analog of argv[0] of the C language in PL/SQL that provides the package (and method)? names? this way, I can proof against the careless programmer mis-typing.
(iii) Apart from writing to the db table and perhaps sending e-mail, are there any significant methods to this package that have escaped my admittedly cursory analysis?
(iv) I am thinking of making it refuse to accept null values for the fields which would force the invoker to populate them when he or she throws an exception. Are there any other things I should force?
Thanks,
Srini

Answer 1

Firstly this is not "error handling" it is logging. They are two different things.
Secondly, before you go any further down this road I recommend you check out log4plsql. This does quite a lot of what you want and a whole lot more besides. It is not perfect (I discuss some of its shortcomings here but it is a very good starting point.
Some specifics:
6. The author who wrote the code.If you know the PACKAGE/METHOD names and you know the version of the software deployed in that environment surely your software version control software will tell you this info?
ii) Is there an analog of argv[0] of the C language in PL/SQL that provides the package (and method)? names?No. Unfortunately PL/SQL lacks this sort of refection, it would be very useful. One tactic is to expand the logging to include INFO and DEBUG levels, which can be turned off (log4plsql does this). Then the developer gets some benefit from the logging package and that is an incentive to get the names right. Another approach is to use an IDE (such as TextPad) that supports clip libraries; include your logger registration call in the templates for PACKAGE, PROCEDURE and FUNCTION.
(iii) Apart from writing to the db table and perhaps sending e-mail, are there any significant methods to this package that have escaped my admittedly cursory analysis?Syslog. It is then industry standard. Some people like files.
(iv) I am thinking of making it refuse to accept null values for the fields which would force the invoker to populate themI think it is an important principle that logging should be as robust as possible - we don't want a gnarly exception thrown because the logging package failed to handle a trivial issue.
You will get the maximum uptake of your logging package if its API is easy to use and developers can see ready benefits from making it work. Again, DEBUG is the key here: all you need do is make it easier to use your package than typing (and removing!) DBMS_OUTPUT.PUT_LINE calls.
Cheers, APC