Geek Answers Handbook

Try to catch every db connection?

Is it recommended to put a try-catch block in each function that opens a connection to the database and register an error there, or should I rather catch errors at a higher level of the application?

public static Category GetCategoryByName(string name) { Category result; try { using (IDbConnection conn = ConnectionHelper.CreateDbConnectionByName(_connectionStringName)) { conn.Open(); using (IDbCommand cmd = conn.CreateCommand()) { //do stuff } } } catch(Exception e) { // log error here? } return result; }

or rather

 try { Category myCat = DataTools.GetCategoryByName("myCat"); // other stuff } catch(Exception e) { // log error here? }

To summarize: Should errors be caught as early as possible in the code? Or should I rather catch them, where I have more information about the context?

+7
source share
4 answers

As always, it depends, but in general, just catch the exception if you can do something with it, or you have a specific code (for example, repetition), otherwise, let this bubble bubble up and the topmost layer can register it / deal with him in a centralized manner.

Any other method results in a lot of logging code interspersed with all business logic.

+13
source

When using exceptions, always try to use the most accurate exception. For example, when using SQL Server, catch the SqlException, because it will contain much more information about the exception than the general exception. You can get actual line numbers and other useful pieces of diagnostic information.

Once you have caught and registered everything that is relevant, discard the exception or wrap it in a less specific exception, such as an InvalidDataException or Exception, and throw it. You can then catch these more general exceptions at higher levels.

 try { // Execute DB call here } catch(SqlException exp) { // Log what you need from here. throw new InvalidOperationException("Data could not be read", exp); }

When you call this method from a higher level, you can just catch an InvalidOperationException. If higher levels require more details, an InnerException will provide a SqlException that can be accessed.

The general approach to handling exceptions that I follow is only to catch what I can usefully work on. It makes no sense to throw a truly general exception to lower levels of code, since you can really expect that everything will go wrong or be able to recover from any exception, for example. OutOfMemoryException or StackOverflowException.

+6
source

I like the first approach better, but you still have to decide what else to do in the catch block ...

  • Restore an exception?
  • throw another (more general) exception?
  • returns null to the caller?
0
source

I usually handle exceptions only in the user interface, all below that I always return it to the top level. Thus, the stack trace was saved to the end. You can always go in and drop it.

I also used this:

 try { DB Command } catch (Exception ex) { Log(ex) throw; //preserve stacktrace }
0
source

More articles:


All Articles