Re: enhanced error fields

Peter Eisentraut <peter_e(at)gmx(dot)net> writes:
> On 12/28/12 2:03 PM, Peter Geoghegan wrote:
>> None of the Python built-in exception types have this kind of
>> information available from fields or anything.

> Sure, OSError has a filename attribute (which I'm sure is qualified by a
> directory name if necessary), SyntaxError has filename, lineno, etc.

No no no ... that's completely unrelated. Those fields report
information about the user-visible object that the error is about.

The point Peter G is making is that reporting the source of the error is
like having the kernel report the name of the function inside the kernel
that threw the error. Or perhaps the name of the kernel source file
containing that function.

Now, these things are quite useful *to a kernel developer* who's trying
to debug a problem involving an error report. But they're pretty
useless to an application developer, and certainly any application
developer who relied on such information to control his error handling
code would receive no sympathy when (not if) a new kernel version broke
it.

In the same way, the filename/lineno stuff that we include in ereports
is sometimes useful to Postgres developers --- but it is very hard to
see a reason why application code would do anything else with it except
possibly print it for human reference.

And, in the same way, a CONTEXT traceback is sometimes useful for
debugging a collection of server-side functions --- but it's hard to see
any client-side code using that information in a mechanized way, at
least not while respecting a sane degree of separation between
server-side and client-side code.

So I'm with Peter G on this: the existing CONTEXT mechanism is good
enough, we do not need to split out selected sub-parts of that as
separate error fields. Moreover, doing so would provide only an utterly
arbitrary subset of the context stack: who's to say whether it would be
more important to report the most closely nested function, or the
outermost one?

regards, tom lane