Thread: AW: Re: More on elog and error codes

AW: Re: More on elog and error codes

From
Zeugswetter Andreas SB
Date:
> > So we need some good error numbering scheme.  Any ideas?
> 
> SQL9x specifies some error codes, with no particular numbering scheme
> other than negative numbers indicate a problem afaicr.
> 
> Shouldn't we map to those where possible?

Yes, it defines at least a few dozen char(5) error codes. These are hierarchical, 
grouped into Warnings and Errors, and have room for implementation specific 
message codes.
Imho there is no room for inventing something new here, or only in addition.

Andreas


Re: AW: Re: More on elog and error codes

From
Peter Eisentraut
Date:
Zeugswetter Andreas SB writes:

> > SQL9x specifies some error codes, with no particular numbering scheme
> > other than negative numbers indicate a problem afaicr.
> >
> > Shouldn't we map to those where possible?
>
> Yes, it defines at least a few dozen char(5) error codes. These are hierarchical,
> grouped into Warnings and Errors, and have room for implementation specific
> message codes.

Let's use those then to start with.

Anyone got a good idea for a client API to this?  I think we could just
prefix the actual message with the error code, at least as a start.
Since they're all fixed width the client could take them apart easily.  I
recall other RDBMS' (Oracle?) also having an error code before each
message.

-- 
Peter Eisentraut      peter_e@gmx.net       http://yi.org/peter-e/



Re: AW: Re: More on elog and error codes

From
Larry Rosenman
Date:
Coming from an IBM Mainframe background, I'm used to ALL OS/Product 
messages having a message number, and a fat messages and codes book.

I hope we can do that eventually. 
(maybe a database of the error numbers and codes?)

LER


>>>>>>>>>>>>>>>>>> Original Message <<<<<<<<<<<<<<<<<<

On 3/20/01, 10:53:42 AM, Peter Eisentraut <peter_e@gmx.net> wrote regarding 
Re: AW: [HACKERS] Re: More on elog and error codes:


> Zeugswetter Andreas SB writes:

> > > SQL9x specifies some error codes, with no particular numbering scheme
> > > other than negative numbers indicate a problem afaicr.
> > >
> > > Shouldn't we map to those where possible?
> >
> > Yes, it defines at least a few dozen char(5) error codes. These are 
hierarchical,
> > grouped into Warnings and Errors, and have room for implementation 
specific
> > message codes.

> Let's use those then to start with.

> Anyone got a good idea for a client API to this?  I think we could just
> prefix the actual message with the error code, at least as a start.
> Since they're all fixed width the client could take them apart easily.  I
> recall other RDBMS' (Oracle?) also having an error code before each
> message.

> --
> Peter Eisentraut      peter_e@gmx.net       http://yi.org/peter-e/


> ---------------------------(end of broadcast)---------------------------
> TIP 5: Have you checked our extensive FAQ?

> http://www.postgresql.org/users-lounge/docs/faq.html


RE: Re: More on elog and error codes

From
"Otto A. Hirr, Jr."
Date:
> So we need some good error numbering scheme.  Any ideas?

I'm a newbie, but have been following dev and have a few comments
and these are thoughts not criticisms:

1) I've seen a huge mixture of "how to implement" to support some  desired feature without first knowing "all" of the
featuresthat  are desired.  Examination over all of the mailings reveals some  but not all of possible features you may
wantto include.
 
2) Define what you want to have without worrying about how to do it.
3) Design something that can implement all of the features.
4) Reconsider design if there are performance issues.

e.g.

Features desired
* system
* subsystem
* function
* file, line, etc
* severity
* user-ability-to-recover
* standards conformance - e.g.. SQL std
* default msg statement
* locale msg statement lookup mech, os dep or indep (careful here)
* success/warning/failure
* semantic taxonomy
* syntactic taxonomy
* forced to user, available to api, logging or not, tracing
* concept of level
* reports filtering on some attribute
* interoperation with existing system reports e.g. syslog, event log,...
* system environment snapshot option (e.g. resource low/empty may/should trigger a log of conn cnt,  sys resource
counts,load, etc)
 
* non-mnemonic internal numbers (mnemonic only to obey stds and then only as a function call, not by implementation)
* ease of use (i.e. pgsql-dev-hacker use)
* ease of use (i.e. api development use)
* ease of use (i.e. rolling into an existing system, e.g. during             transition both may need to be in use.)
* ease of use (i.e. looking through existing errors to find one             that may "correctly" fit the situation,
insteadof             creating yet-another-error-message.)
 
* ease of use (i.e. maybe having each "sub-system" having its own             "error domain" but using the same error
mechanism)
* distinction btwn error report, debug report, tracing report, etc
* separate the concepts of - report creation - report delivery - report reception - report interpretation
* what do other's do, other's as in os, db, middleware, etc along with their strong and weak points
... what else do you want... and lets flesh out the meaning of
each of these.  Then we can go on to a design...

Sorry if this sounds like a lecture.

With regards to mnemonic things - ugh - this is a database.
I've worked with a LARGE electronics company that had
10 and 12 digit mnemonic part numbers.  The mnemonic-ness
begins to break down.  (So you have a part number of an eprom,
what is the part number when it is blown - still an eprom?
how about including the version of the sw on the eprom? is it
now an assembly?  opps that tended to mean multiple parts attached
together, humm still looks like an eprom?)  They have gone through
a huge transition to move away, as has the industry from mnemonic
numbers to simply an id number.  You look up the id number in a
>database< :-) to find out what it is.

So why not drop the mnemonic concept and apply a function to a
blackbox dataitem to determine its attribute?  But again first
determine what attributes you want, which are mandatory, optional,
system supplied (e.g. __LINE__ etc), is it for erroring, tracing,
debugging, some combo; then the appropriate dataitem can be
designed and functions defined.  Functions (macros) for both the
report creation, report distribution, report reception, and
report interpretation.  Some other email pointed out that
there are different people doing different things.  Each of these
people-groups should identify what they need with regards to
error, debug, tracing reports.  Each may have some nuances that
are not needed elsewhere, but the reporting system should be able
to support them all.

Ok, so I've got my flame suit on...  but I am really trying to give
an "outsiders" birdseye view of what I've been reading, hopefully
which may be helpful.

Best regards,

.. Otto

Otto Hirr
OLAB Inc.
otto.hirr@olabinc.com
503 / 617-6595