Re: enhanced error fields

From: Peter Geoghegan <peter(at)2ndquadrant(dot)com>
To: Pavel Stehule <pavel(dot)stehule(at)gmail(dot)com>
Cc: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, Stephen Frost <sfrost(at)snowman(dot)net>, PostgreSQL Hackers <pgsql-hackers(at)postgresql(dot)org>, Alvaro Herrera <alvherre(at)commandprompt(dot)com>
Subject: Re: enhanced error fields
Date: 2012-12-28 19:03:14
Message-ID: CAEYLb_VCXqM6gVVD7rrghGnYExDD9HdOC9V+0hV8H3=orqrapA@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On 28 December 2012 18:40, Pavel Stehule <pavel(dot)stehule(at)gmail(dot)com> wrote:
> If
> I understand you, we have a fields that has behave that you expected -
> filename and funcname. And I have not used these fields for
> application programming.

No, that's not what I mean. What I mean is that it seems questionable
to want to do anything *within* an exception handler on the basis of
where an exception was raised from. You should just place exception
handlers more carefully instead.

Are you aware of any popular programming language that provides this
kind of information? Can you tell in a well-principled way what
function a Python exception originated from, for example? These are
the built-in Python 2 exception classes:

http://docs.python.org/2/library/exceptions.html

None of the Python built-in exception types have this kind of
information available from fields or anything. Now, you might say that
Python isn't Postgres, and you'd be right. I'm fairly confident that
you'll find no precedent for a routine_name field in any code that is
even roughly analogous to the elog infrastructure, though, because
acting on the basis of what particular function the exception was
raised from seems quite hazardous - it breaks any kind of
encapsulation that might have existed.

If one person slightly refactors their code, it could break the code
of another person who has never even met or talked to the first.

--
Peter Geoghegan http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Training and Services

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Pavel Stehule 2012-12-28 19:23:28 Re: enhanced error fields
Previous Message Josh Berkus 2012-12-28 18:53:05 Re: Proposal: Store "timestamptz" of database creation on "pg_database"