C#

Derek Bartram wrote:

Does anyone know if a try...catch block affects the performance of the try block code? I know it has a performance hit on hitting the block, but I wonder if it has a continuing effect beyond that.

---

I'm largely language agnostic

---

After a while they all bug me

---

try
{
}
catch...

public static bool someMethod()
{
    try
    {
        //code process
        if(somthing wrong)
        {
             throw new Exception("Error!!");
        }
    }
    catch(Exception err)
    {
        return false;
    }
}

Spacix One wrote:

The problem is when Exceptions do occur it slows everything down. Though I think that is better than the WHOLE app crashing to a grinding halt and a .NET error message dialog showing then the Microsoft error reporting tool (if enabled) poping up.

---

I'm largely language agnostic

---

After a while they all bug me

---

static FileStream openFile(string filePath)
{
    FileStream fs;
    try
    {
        fs = File.OpenRead(filePath);
    }
    catch (FileNotFoundException err)
    {
        File.Create(filePath);
        fs = File.OpenRead(filePath);
    }
    return fs;
}

---

-Spacix
All your skynet questions[^] belong to solved

---

I dislike the black-and-white voting system on questions/answers.

---

MidwestLimey wrote:

I once worked on a project where the Project Lead insisted on try catch blocks in every bloody method.

MidwestLimey wrote:

I did some performance testing and could determine definitive costs with the setup and teardown of the block, but was unable to measure any discernable difference to the code internally.

However the code was entirely managed, perhaps wrapping unmanaged code has other implications.

Derek Bartram wrote:

to avoid using try...catch as much as possible due to the massive performance hit it

George_George wrote:

But confused what means "catching untestable errors"

George_George wrote:

"not controlling programming flow"?

try
{
double y = 100.0 / slider.Value
}
catch (Exception)
{
//handler exception
}

is a bad way to write this code (remembing slider.Value could be 0 causing divide by 0 exception), a better way would be....

if (slider.Value != 0)
{
double y = 100.0 / slider.Value
}
else
{
handle error
} 

Derek Bartram wrote:

massive performance hit