Is it possible to change this code, with a return value and an exception:
public Foo Bar(Bar b)
{
if(b.Success)
{
return b;
}
else
{
throw n.Exception;
}
}
to this, which throws separate exceptions for success and failure
public Foo Bar(Bar b)
{
throw b.Success ? new BarException(b) : new FooException();
}
try
{
Bar(b)
}
catch(BarException bex)
{
return ex.Bar;
}
catch(FooException fex)
{
Console.WriteLine(fex.Message);
}
Throwing an exception is definitely more expensive than returning a value. But in terms of raw cost it's hard to say how much more expensive an exception is.
When deciding on a return value vs. an exception you should always consider the following rule.
Only use exceptions for exceptional circumstances
They shouldn't ever be used for general control flow.
In some recent real work performance analysis, we found that tons of exceptions on lower end machines had a critical effect on the application performance, so much so that we are devoting a few weeks to go through and adjust the code to not throw so many.
When I say a critical effect, it was in the ballpark of spiking the dual core CPU up to 95% on the single CPU core the application was using.
I'm having trouble at the moment finding any documents to support it, but keep in mind that when you throw an exception, C# has to generate a stack trace from the point where you called it. Stack traces (and reflection in general) are far from free.
You should prefer Exceptions over error codes, and for error conditions, but don't use exceptions for normal program flow.
Exceptions are extremely heavy duty compared to normal work flow, I've seen a huge order of magnitude decrease in application performance using a try-catch-block.
Using error returns will be much more expensive than exceptions - as soon as a piece of code forgets to check the error return, or fails to propagate it.
Still, be sure to not use exceptions for control flow - use them only to indicate that something has gone wrong.
You can find a lot of useful information about this in the answers to this question, including one answer with 45 up-votes How slow are .net exceptions?
Exception have two costs: warm-up to page in the exception infrastructure - if not in to memory then into the CPU cache - and per-throw cost to gather exception stack, search for exception handler, possibly call exception filters, unwind the stack, calling finalization blocks - all operations that the runtime, by design, does not optimize for.
Thus, measuring the cost of throwing exceptions can be misleading. If you write a loop that iteratively throws and catches an exception, without a lot of work between the throw site and the catch site, the cost won't look that large. However, that's because it's amortizing the warm-up cost of exceptions, and that cost is harder to measure.
Certainly, exceptions don't cost anything like they seem to if one's main experience is exceptions thrown by programs under the debugger. But they do cost, and it's advisable to design libraries in particular such that exceptions can be avoided where necessary for optimization.
Throwing an exception is a relatively inexpensive operation. It's catching them that incurrs the cost because of the stack walks that must occur to find the catch handlers, execute the code in the catch handlers, find the finally blocks, execute the code in the finally blocks, and then return to the original caller.
It is strongly recommended that you don't use exceptions for control flow. Using return codes to indicate errors gets expensive from a "time and materials" perspective as it will eventually incur maintenance costs.
All of that aside, your two examples don't match nor are they even valid. Since you are return b, which is of type Bar, your first method should probably be:
public Bar Foo(Bar b)
{
if(b.Success)
{
return b;
}
else
{
throw n.Exception;
}
}
which could be rewritten as:
public Bar Foo(Bar b)
{
if (!b.Success)
throw n.Exception;
return b;
}
Generally I've avoided this because of the expensive nature of catching the exception. It may not be too bad if it's not something that happens often.
However, why not just return null? Then it becomes this:
public Foo Bar(Bar b)
{
if(b.Success)
{
return b;
}
else
{
return null;
}
}
And then whenever you call Bar() you just check to ensure that the returned value is not null before using the value. This is a far less expensive operation. And I figure it's a good practice because this is the technique Microsoft has used all over the place in many of .NET's built-in functions.
Using the code below, testing revealed that the the call+return with no exceptions took about 1.6 microseconds per iteration, whereas exceptions (throw plus catch) added about 4000 microseconds each.(!)
public partial class Form1 : Form
{
public Form1()
{
InitializeComponent();
}
private void button1_Click(object sender, EventArgs e)
{
DateTime start = DateTime.Now;
bool PreCheck = chkPrecheck.Checked;
bool NoThrow = chkNoThrow.Checked;
int divisor = (chkZero.Checked ? 0 : 1);
int Iterations = Convert.ToInt32(txtIterations.Text);
int i = 0;
ExceptionTest x = new ExceptionTest();
int r = -2;
int stat = 0;
for(i=0; i < Iterations; i++)
{
try
{
r = x.TryDivide(divisor, PreCheck, NoThrow);
}
catch
{
stat = -3;
}
}
DateTime stop = DateTime.Now;
TimeSpan elapsed = stop - start;
txtTime.Text = elapsed.TotalMilliseconds.ToString();
txtReturn.Text = r.ToString();
txtStatus.Text = stat.ToString();
}
}
class ExceptionTest
{
public int TryDivide(int quotient, bool precheck, bool nothrow)
{
if (precheck)
{
if (quotient == 0)
{
if (nothrow)
{
return -9;
}
else
{
throw new DivideByZeroException();
}
}
}
else
{
try
{
int a;
a = 1 / quotient;
return a;
}
catch
{
if (nothrow)
{
return -9;
}
else
{
throw;
}
}
}
return -1;
}
}
So yes, Exceptions are VERY expensive.
And before someone says it, YES, I tested this in Release mode and not just Debug mode. Try the code yourself and see if you get significantly different results.