views:

181

answers:

2

which is more efficient/better code. to use is object and then unbox if it is that type of object?? or use try catch

WizardStep parentWizardStep;    
try
 {
   parentWizardStep = (WizardStep)this.Parent;
 }
catch
{
   throw new Exception("Unable to cast parent control to this type.");
}

OR THIS:

WizardStep parentWizardStep;         
if(this.Parent is WizardStep) 
{ 
    parentWizardStep= (WizardStep)this.Parent; 
} 
else  
{  
    throw new Exception("Unable to cast parent control to this type."); 
}
+17  A: 

If you need to throw an exception when the cast is invalid, why are you bothering to catch the normal InvalidCastException? Just cast it with no extra code:

WizardStep parentWizardStep = (WizardStep) Parent;

You're currently replacing an exception which conveys its meaning in its type (InvalidCastException - at least, so you hope) with bare Exception - why do you want to lose information?

The above is certainly what I always do if it's a bug for the relevant value to not be of the correct type. Otherwise, use the as operator and a null check:

WizardStep parentWizardStep = Parent as WizardStep;
if (parentWizardStep == null)
{
    // It wasn't a WizardStep. Handle appropriately
}
else
{
    // Use the WizardStep however you want
}

But either way, it's horrible to do something that you know might throw an exception, and where it's easy to test to avoid the exception, but choosing to catch it instead. The efficiency will be poor, but more importantly it's just an inappropriate use of exceptions. Aside from anything else, you're currently catching all exceptions... what if fetching this.Parent throws some completely different kind of exception? It may have nothing to do with casting. Only catch specific exceptions unless you're trying to implement some top-level "catch-all" handler (e.g. to abort server requests).

Jon Skeet
Very good point. I was assuming there was probably more to this than just re-raising a IllegalCastException, but if not, this is the best option...
Reed Copsey
Agree. If you actually need to trap the exception and do something other than re-throw, then use the try/catch block. Otherwise just do as @Jon says.
Brian Driscoll
One minor quibble. There are times (though this probably isn't one of them) where you do want to catch a specific exception and then wrap it http://msdn.microsoft.com/en-us/library/ms229049.aspx
Conrad Frix
@Conrad: Yes, occasionally you would wrap it, but as you say you would catch a *specific* exception, and then throw a different *specific* exception... to convey different information, while preserving the original information in the InnerException. Not what's happening here :)
Jon Skeet
Just elaborating on Jon's remarks: This would be an example of using exceptions to control business logic, which is bad practice because it (a) gives the the reader the impression that this won't generally happen, (b) results in worse performance, (c) makes advanced debugging sessions harder (as it seems that there are endless exceptions in there which aren't real exceptions). There are probably other reasons as well.
steinar
+5  A: 

It is more efficient to use as instead:

WizardStep parentWizardStep = this.Parent as WizardStep;
if(parentWizardStep == null)
{
     // This isn't the right type
     throw new ApplicationException("Your exception here.");
}

// Use parentWizardStep here....
Reed Copsey