Design question regarding exceptions.

[asincero]

I have a class called Users that provides a higher level of
abstraction to an underlying "users" table in a pgsql database. It
has methods like "addUser()" and "deleteUser()" which, obviously, wrap
the corresponding SQL statements. My question is would it better to
let any exceptions thrown by the underlying DB-API calls bubble up
from these methods, or should I catch them inside the methods, wrap
them inside my own custom exceptions, and throw those exceptions
instead?

Thanks.

-- Arcadio

 

[James Stroud]

I have a class called Users that provides a higher level of
abstraction to an underlying "users" table in a pgsql database. It
has methods like "addUser()" and "deleteUser()" which, obviously, wrap
the corresponding SQL statements. My question is would it better to
let any exceptions thrown by the underlying DB-API calls bubble up
from these methods, or should I catch them inside the methods, wrap
them inside my own custom exceptions, and throw those exceptions
instead?

Thanks.

-- Arcadio

I don't think its wise to mask or otherwise waste cpu cycles catching
and re-throwing lower level exceptions. If you anticipate problems with
certain inputs, test for those possibilities and raise custom exceptions
at module level. At package level, you can import a module with your
package exceptions defined.

James

--
James Stroud
UCLA-DOE Institute for Genomics and Proteomics
Box 951570
Los Angeles, CA 90095

http://www.jamesstroud.com/

 

[Bruno Desthuilliers]

asincero a écrit :

I have a class called Users that provides a higher level of
abstraction to an underlying "users" table in a pgsql database. It
has methods like "addUser()" and "deleteUser()" which, obviously, wrap
the corresponding SQL statements. My question is would it better to
let any exceptions thrown by the underlying DB-API calls bubble up
from these methods, or should I catch them inside the methods, wrap
them inside my own custom exceptions, and throw those exceptions
instead?

There's no absolute answer to this. But unless your "abstraction layer"
is supposed to be usable with non-DB-API backends (ie: text files, LDAP,
etc), I don't see any reason to abstract the exceptions.