Simple Question

[Laeg]

Say I want a function to always return true or false even if an exception is thrown, is the following correct?

public bool FooBar(){

try{
PossibleDodgyMethod();
return true;
}
catch (Exception ex){
return false;
throw MyCustomException;
}
}

Am I right in saying that no code after the throw is executed?

 

[Guru7777]

I believe that throw won't even be executed. Your return statement will get you out of there and the next line is superfluous.

----------------------------------------

TWljcm8kb2Z0J3MgIzEgRmFuIQ==

 

[Laeg]

So it is an either or really.

throw the exception or return a boolean

 

[jmeckley]

Guru777 that is incorrect. if PossibleDodgyMethod() throws an exception the next line will not be reached. Laeg is correct with the try/catch block to return false.

however the catch block is throwing a custom exception, so return false is not required. FooBar() will either return true of throw an exception. it will never return false.

the catch block should either throw a custom exception or return false, but not both.

BTW if you are going to throw a custom exception you should wrap the actual exception, instead of swallowing it. right now you loose all information about the actual exception thrown.

if you change it to this

public bool FooBar()
{
   try
   {
      PossibleDodgyMethod();
      return true;
   }
   catch(Exception e)
   {
       throw new MyCustomException(e);
   }
}

public class MyCustomException : Exception
{
   public MyCustomException(Exception exception)
      :base("your error message", exception)
   {
   }
}

you will preserve the actual error which can be logged up the stack.

Jason Meckley
Programmer
Specialty Bakers, Inc.

 

[Guru7777]

jmeckley, I was talking about the return false in the catch block. My point was that returning false would prevent the throw from being executed and that the line didn't make any sense to be there in that example (superfluous). I was pointing out that you can't throw an exception and return a value (in the false case not in the method as a whole... the true/exception mixed case), the same as Laeg was.

I wasn't making a judgement call on the correct way to design an application. Best practice says you should never catch an exception in a library if you aren't going to do anything with it unless it is something you completely expect and you know that it does not matter (like a ThreadAbortException after a Response.Redirect).

----------------------------------------

TWljcm8kb2Z0J3MgIzEgRmFuIQ==

 

[jmeckley]

Now I understand. I though you were talking about the try block, not the catch.

My statement above about returning false and throwing is incorrect. the throw would never happen in the codes current state. not the other way around.

Jason Meckley
Programmer
Specialty Bakers, Inc.