Date: Thu, 4 Oct 2018 14:55:01 +0100
From: Rory Campbell-Lange <rory@campbell-lange.net>
To: Daniele Varrazzo <daniele.varrazzo@gmail.com>
Cc: psycopg@lists.postgresql.org
Subject: Re: Plans for 2.8
Message-ID: <20181004135501.2rvzcg3li4plo77b@campbell-lange.net>
References: 
 <CA+mi_8auWr+u4DwLGnu3JOu=jhMAV_8OPnMtMuXOr+0iMN5LgA@mail.gmail.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: 
 <CA+mi_8auWr+u4DwLGnu3JOu=jhMAV_8OPnMtMuXOr+0iMN5LgA@mail.gmail.com>
User-Agent: NeoMutt/20170113 (1.7.2)
Precedence: bulk

On 04/10/18, Daniele Varrazzo (daniele.varrazzo@gmail.com) wrote:
> The feature I'm the most excited about (and worried about its
> reception) is to raise a different exception for every postgres error
> message (see #682) . For instance `SELECT * FROM wrong_name` will
> raise `UndefinedTable` rather than `ProgrammingError`. Currently
> handling a specific exception requires catching a broader class and
> looking at the pgcode:
> 
>     try:
>         cur.execute("lock table %s in access exclusive mode nowait" % name)
>     except psycopg2.OperationalError as e:
>         if e.pgcode == psycopg2.errorcodes.LOCK_NOT_AVAILABLE:
>             locked = True
>         else:
>             raise
> 
> This can become a much more natural:
> 
>     try:
>         cur.execute("lock table %s in access exclusive mode nowait" % name)
>     except psycopg2.errors.LockNotAvailable:
>             locked = True
> 
> The error classes are generated automatically from Postgres source
> code and are subclasses of the previously existing ones, so existing
> code should be unaffected. I'd be happy to have input about the
> feature and suggestions before releasing it.

Hi Daniele

The greater depth of exception reporting looks great to me, particularly
if they are subclasses of the existing ones.

Regards
Rory