CODEWITHSUNDEEP
c#try-catch
Harry
Harry

Reputation: 3195

Wrap every method in try-catch or specific part of code

My senior colleague tells me to wrap every method within a try-catch block so they can trace where exceptions occurs to help debug issues quicker. Is it better to wrap every method in a Try Catch such as this to:

Public int foo()
{
   try
   {
       //do something
   }catch(Exeception ex)
   {
       //do something with ex
   }
}

Or is it better to catch exceptions where I think they may occur? E.g. doing something with an array may cause the IndexOutOfRangeException will occur.

//wrap this in try catch
    int[] array = new int[3];

                array[0] = 1;
                array[1] = 2;
                array[2] = 3;
                array[3] = 4;

Thanks.

Upvotes: 13

Views: 25592

Answers (5)

S. Gmiden
S. Gmiden

Reputation: 155

Using try-catch depends strongly on the context. For me there's no rules to tell developer when using or not a try catch block.

Developer code must prevent the evident errors or exceptions due to context like null parameters or file existence or the data coherency. In case of developing a library used by many other programs, the library catches only some critical exception to allow top level programs have more details about errors and exceptions.

For example, we have a method in library using System.IO.File.WriteAllLines.

void bool DoSomethingWithFile()
{
  try
  {
     // Some code here
     System.IO.File.WriteAllLines()
     //some code here
     return true;
  }
  catch()
  {
     LogExeption();
     return false;
  }
}

How to tell top level program that the PathTooLongException or there's a security exception unless you add throw in the catch block.

Upvotes: -1

Rohit
Rohit

Reputation: 10236

There is no problem in using Try catch block as it has no overhead (unless if you keep adding it everywhere which might include overhead in readability) while there is often additional IL added for catch and finally blocks,when no exception is thrown there is little difference in behaviour.

However if your code does throw an exception this is where you have a slight performance issue as in such cases an exception must be created,stack crawl marks must be placed and, if the exception is handled and its StackTrace property accessed, a stack walk is incurred. so as a result it might not be good idea to always wrap your code in try catch block alternatively you can place it at a parent level and then inspect the stack trace

Upvotes: 0

Goran Rojovic
Goran Rojovic

Reputation: 1

Every piece of code where you think an error may occur should be wraped inside try catch block. If you are working on some real time problems and applications you should use it everywhere. It is a good programing practice. If you don't know what exception could occur, just use catch block for general exceptions:

try
{
   //your code
}
catch (Exception ex)
{
   //exception handling
}

Or you could use:

try
{
   //your code
}
catch
{
   //your custom message
}

Upvotes: -4

Mohit S
Mohit S

Reputation: 14044

The try block contains the guarded code that may cause the exception. The block is executed until an exception is thrown or it is completed successfully.

You can have a look on How often should I use try and catch

The basic rule of thumb for catching exceptions is to catch exceptions if and only if you have a meaningful way of handling them.

Don't catch an exception if you're only going to log the exception and throw it up the stack. It serves no meaning and clutters code.

Do catch an exception when you are expecting a failure in a specific part of your code, and if you have a fallback for it.

Of course you always have the case of checked exceptions which require you to use try/catch blocks, in which case you have no other choice. Even with a checked exception, make sure you log properly and handle as cleanly as possible.

Upvotes: 18

user834850
user834850

Reputation:

Better to use it in critical parts of your code and then:

[STAThread]
static void Main()
{
    Application.EnableVisualStyles();
    Application.SetCompatibleTextRenderingDefault(false);
    Application.ThreadException += new ThreadExceptionEventHandler(Application_ThreadException);
    AppDomain.CurrentDomain.UnhandledException += new UnhandledExceptionEventHandler(CurrentDomain_UnhandledException);
    ServerForm form = new ServerForm();
    Application.Run(form);
}
static void Application_ThreadException(object sender, ThreadExceptionEventArgs e)
{
    MessageBox.Show(e.Exception.Message, Program.Name);
}

static void CurrentDomain_UnhandledException(object sender, UnhandledExceptionEventArgs e)
{
    MessageBox.Show((e.ExceptionObject as Exception).Message, Program.Name);
}

just in case of unhandled Exception

Upvotes: 1

Related Questions