views:

74

answers:

3

Hi,

I have a method which handles a set of records.This method,return true\false after processing.So,if all the records are processed(doing some db updates),will return true.Now,suppose after processing 1 record,some exception is thrown,should I write result=false(at the end of method result is returned) in catch block? And,allow processing of other records to be done?

A: 

I think it could be something like that

    int count = 0;
    foreach( item in list)
    {

    try
    {
     //update DB
     ++count;
    }
    catch(Exception ex)
    {
         //log exception
    }
    if(count == list.Count)
      return true;
     else return false;

   }

Another way

 bool result = true;
 foreach( item in list)
 {

   try
   {
     //update DB
   }
   catch(Exception ex)
   {
      //log exception
      result = false;
   }
  return result;
 }
Ahmed Said
yeh,we are doing this.In exception block,we log the exception
jess
@Ahmed: This is a wrong example: Empty catch blocks are highly discouraged.
Marek
I updated my code
Ahmed Said
A: 

How you handle this with exceptions will be determined very much by what you want to happen in the event of something going wrong. You could, as you say, just write result= false in your catch blocks, but this means you are simply saying to the calling function "Hey - some records were not processed - live with it...". That might be enough for you - it depends what you're trying to do.

At the very least though, I would want to also write the details of the exceptions away to a log. And if you don't have a method somewhere that takes an exception and writes away to a log, it's time to write one (or use a third party solution...)

Otherwise you are losing information that could be useful in determining why things failed...

Whether you process those records you can or throw everything out in the event of a problem is a design question that only you can answer - we don't have the context...

Martin Milan
+1  A: 

Continuing to add data to the dbase when adding one record failed is almost always wrong. Records are very frequently related. They represent a set of transactions on a bank account. Or a batch of orders from a customer. Adding these with one of them missing is always a problem.

Not only do you give your client a huge problem coming up with a new batch that contains the single corrected record, you make it far too easy to allow somebody to just ignore the error. The kind of error that doesn't get discovered or causes problems until much later. Invariably with a huge cost associated with correcting the error.

When an error occurs, reject the entire batch. Keep the dbase in a proper state by using transactions. Use, say, SqlTransaction and call BeginTransaction() when you start. Call Commit() when everything worked, call Rollback() in your catch clause.

Your client can now go back to the sub-system that generates the records, make the correction and re-run your program. Your dbase will always contain a proper copy of that sub-system's data. And errors cannot be ignored.

Hans Passant