Catching Database Exceptions (Sybase)

[Thomas Gagne]

except Sybase.Warning, env:

That was it!  I needed to specify the module name before "Warning" and
"Error".  Not I'm catching the exception.  It worked for *both* the missing
table and the missing stored procedure.

As a side note, all errors and warning detected in the database are reported
back to the client application as either Messages or Errors.  Now I'm going to
see where the text of RAISERROR and PRINT statements ends up...

David Bolen wrote:

> Thomas Gagne <tgagne at ix.netcom.com> writes:
>
> > And miraculously, even with the table missing, it ran the "else".
> >
> > I must be missing something significant here.  Any help?
>
> You might try the same operation via some other tool (e.g., ISQL or
> equivalent).  It's my understanding from some of the DB folks here
> that depending on the type of error, errors within stored procedures
> may sometimes be simply absorbed and not reported - you just get back
> an empty result.  I know I've run some stored procedures that had bad
> references to fields that didn't exist and didn't actually get a
> database error from the execution, just no result.
>
> And to answer your follow-up post question, the Warning and Error
> classes that the DB API specifies all exceptions must be subclassed
> from are themselves DB API-specific exceptions (both are subclasses of
> the standard Python exception StandardError).
>
> So in your exception clauses try using "<module>.Warning" instead of
> just "Warning" (where <module> is your DB API compliant module).

--
.tom