But in my opinion this discussion shouldn't really even be about catching these things, most of the times you won't catch them and instead you'll let them go to Postgres. The discussion should be whether raise plpy.Error(...), plpy.raise_error, plpy.raise_info(,,,) etc. all with keyword argument support are a good PLPython interface to Postgres' ereport. I think they are.
I removed from previous patch all OOP related changes. New patch contains raise_xxxx functions only. This interface is new generation of previous functions: info, notice, warning, error with keyword parameters interface. I didn't changed older functions due keeping compatibility.
I spent lot of time with experiments how to merge PostgreSQL exception system with Python exception system. But I didn't find a solution without some design issues. These concepts(s) are too different (note: there are two concepts: PostgreSQL levels and ANSI SQL SQLSTATE (class, subclass codes).
I hope so raise_xxxx has benefit for PLPythonu users too. Currently users has to use ugly workaround to raise rich PostgreSQL exception from Python. With new function all available functionality related to PostgreSQL exception can be used simply.
