Reputation: 12896
It's been a while since my last programming excercises so here's a rather basic question. However I couldn't find any concrete answer yet.
Let's say I have defined a method which might cause an exception. The method would look like this (in rather pseudo-code):
public int Calculate(int x, int y)
{
try
{
doSomeCalc();
}
catch (SomeException ex)
{
doExceptionHandling();
}
return result;
}
Now if another part of the application wants to use this method should it use another try-catch block?
public MyMainApp() {
try
{
Calculate(1, 2);
}
catch (SomeException ex)
{
doExceptionHandling();
}
}
So the question here is where should I use try-catch and where is it superfluous?
Upvotes: 1
Views: 3484
Reputation: 460108
If Calculate
already catches the exception and handles it, why should MyMainApp
care about it at all? If it does not catch it, MyMainApp
might want to handle it. It should not catch it if it doesn't handle it in a useful way(at least log the exception).
Best-practise is to throw meaningful exceptions as soon as possible, e.g.(assuming that negative values can cause wrong results or exceptions):
public int Calculate(int x, int y)
{
if (x <= 0)
throw new ArgumentException("X has to be positive", "x");
if (y <= 0)
throw new ArgumentException("Y has to be positive", "y");
// now the calculation should be safe without any side-effects
// ...
}
Upvotes: 2
Reputation: 20575
In general, try-catch should be used when you need to handle error cause by certain statement execution.
For example, In case of Db connectivity, SqlException
is raised that can have information related to the error, like Wrong Password
, Invalid Database
...
try
{
//try connect to db
}
catch (SqlException ex)
{
// information of database related exception
}
catch (Exception ex)
{
// catch any other error
}
Exception Handling
at time is not as simple as it seems.
Please read this article (I personally have learnt a lot from it ) : Exception Handling Best Practices in .NET
Upvotes: 2
Reputation: 32841
Generally, you should only use a try-catch if there is something that you can do in the catch. Can you retry the failed connection or otherwise help the user to continue? Do you want to log the exception?
If there's nothing you can do to recover or gracefully degrade, there is no point in catching the exception. Just let it bubble up to a catch at the top of the app (for example, in the Page_Error event in the base page of a web app) and handle the UI there.
Upvotes: 9
Reputation: 67296
The rule of thumb is that you only catch where you are going to do something with the exception. For example, logging a particular exception or retrying the call.
In order to maintain the stack trace, you usually re-throw the exception using throw;
and then have some mechanism at the top of the process that globally handles errors.
Upvotes: 1
Reputation: 1253
It depends on the SomeException
type. If it is the base class of all exceptions, no, it is not needed in your second block.
However, if it processes only one specific type of exception and it is possible for others to occur, you need a second block.
Why would you need to process only one specific exception? That is for you to find out, if needed :)
Upvotes: 1
Reputation: 23801
Try putting try and catch inside event functions
since normal functions would be called from event functions only.And only use try in other layer functions if some rollbacks
are to be performed.
Hope it helps....
Upvotes: 0