Exception handling / Best Practices

Exception handling / Best Practices

• Martin Schmidt

  I would recommend validating inputs before catch exceptions. the exception catching is there if all else fails. It is also expensive to catch exceptions so validation is preferred before hand, then the exception. This would be best practice. you should validate before proceeding so you know what the possibilites are of the inputs going wrongly before catching the exception. In case of anything seriously going wrong - thats what the exception is there for :-)
  
  

• Matt Lund

  Thank you for your insight. Your two well choosen examples show that there is not one answer (which I had hoped there might be).

  It is still a matter of using both tools. Unfortunately, .NET has expanded the number of tools. For example, I was unaware of .TryParse until you mentioned it. I'm sure there are many, many others as well.

  I was looking to simplify ... but no luck.

  Thanks again

  Roger

  
  
  

• qwv

  Thanks.

  Both your answer and Charles' help me greatly.

  The cost of Exceptions was one of my concerns. I wonder if anyone has explored the relative costs of Exception handling vs. the more traditional method of edits.

  Thanks for your help

  Roger

  
  
  

• BillyB

  usually database exceptions are OleDbException for OleDB and SqlException for SQL exceptions. you could catch the exception but exceptions are sometimes costly and you want to make sure you use the procedure efficiently.

  what exactly are you checking for duplicates the unique key well you shouldnt worry about that if you set the auto increment to true and make it as a primary key for example

  
  
  

• Raybritton

  Hi,

  An easy way to choose to use exception or validation is whether an error can be expected and whether your method can do anything if this error occurs.

  This criteria means that in normal situations, a program should be able to run to completion without throwing a single exception. You can configure VS to break on any exception in debug mode to know exactly when exceptions are thrown.

  For example a function which reads a string from a textbox, converts it to an integer and assigns it to an object's field should use the Int32.TryParse function because it is expected that users enter invalid text.

  Another example is a method which sends data on a socket. If the user has networking problem it is possible that the socket is in an invalid state. The method should not validate the state of the socket because even if it detects the problem it is not clear what should be done (close connection, abort, retry connection). Instead, the method let the exception bubble up the call stack until a higher level method can decide what to do and alert the user of the problem.

  Hope this helps,
  Charles

  
  

• Coroebus

  Although I used a DataBase example in my question, my question is much more general.

  The question is: Is it better to check for errors in the way I have for 50 years -- Pre-processing -- or by using the exception process -- Post-processing.

  I am getting the impression that the 'old' paradigm is no longer valid. Now that the Exception Object is a First Class Object, should this be the the preferred method.

  Possibly another example would be better: Consider Divide-by-Zero --

  Is the preferred method to check for zero in code:

  If x = 0 then ...

  Or, should we use:

  try

  y/x

  catch e as Divide-by-zero

  end try

  Consider -- attempting to 'out-think' all possible errors and test for them occupied a good portion of development time. With Try/Catch many errors that have virtually identical solutions ("Cut-and-Run") back to a form (or other terminating event) can be 'lumped ' together in one Catch.

  On-the-other-hand: is this just an excuse for sloppy programming

  This is where the "Best-Practices" question comes in.

  Roger

  
  
  
• Exception handling / Best Practices