How using try catch for exception handling is best practice
My exception-handling strategy is:
To catch all unhandled exceptions by hooking to the
Application.ThreadException event
, then decide:- For a UI application: to pop it to the user with an apology message (WinForms)
- For a Service or a Console application: log it to a file (service or console)
Then I always enclose every piece of code that is run externally in try/catch
:
- All events fired by the WinForms infrastructure (Load, Click, SelectedChanged...)
- All events fired by third party components
Then I enclose in 'try/catch'
- All the operations that I know might not work all the time (IO operations, calculations with a potential zero division...). In such a case, I throw a new
ApplicationException("custom message", innerException)
to keep track of what really happened
Additionally, I try my best to sort exceptions correctly. There are exceptions which:
need to be shown to the user immediately
require some extra processing to put things together when they happen to avoid cascading problems (ie: put .EndUpdate in the
finally
section during aTreeView
fill)the user does not care, but it is important to know what happened. So I always log them:
In the event log
or in a .log file on the disk
It is a good practice to design some static methods to handle exceptions in the application top level error handlers.
I also force myself to try to:
- Remember ALL exceptions are bubbled up to the top level. It is not necessary to put exception handlers everywhere.
- Reusable or deep called functions does not need to display or log exceptions : they are either bubbled up automatically or rethrown with some custom messages in my exception handlers.
So finally:
Bad:
// DON'T DO THIS; ITS BAD
try
{
...
}
catch
{
// only air...
}
Useless:
// DON'T DO THIS; IT'S USELESS
try
{
...
}
catch(Exception ex)
{
throw ex;
}
Having a try finally without a catch is perfectly valid:
try
{
listView1.BeginUpdate();
// If an exception occurs in the following code, then the finally will be executed
// and the exception will be thrown
...
}
finally
{
// I WANT THIS CODE TO RUN EVENTUALLY REGARDLESS AN EXCEPTION OCCURRED OR NOT
listView1.EndUpdate();
}
What I do at the top level:
// i.e When the user clicks on a button
try
{
...
}
catch(Exception ex)
{
ex.Log(); // Log exception
-- OR --
ex.Log().Display(); // Log exception, then show it to the user with apologies...
}
What I do in some called functions:
// Calculation module
try
{
...
}
catch(Exception ex)
{
// Add useful information to the exception
throw new ApplicationException("Something wrong happened in the calculation module:", ex);
}
// IO module
try
{
...
}
catch(Exception ex)
{
throw new ApplicationException(string.Format("I cannot write the file {0} to {1}", fileName, directoryName), ex);
}
There is a lot to do with exception handling (Custom Exceptions) but those rules that I try to keep in mind are enough for the simple applications I do.
Here is an example of extensions methods to handle caught exceptions a comfortable way. They are implemented in a way they can be chained together, and it is very easy to add your own caught exception processing.
// Usage:
try
{
// boom
}
catch(Exception ex)
{
// Only log exception
ex.Log();
-- OR --
// Only display exception
ex.Display();
-- OR --
// Log, then display exception
ex.Log().Display();
-- OR --
// Add some user-friendly message to an exception
new ApplicationException("Unable to calculate !", ex).Log().Display();
}
// Extension methods
internal static Exception Log(this Exception ex)
{
File.AppendAllText("CaughtExceptions" + DateTime.Now.ToString("yyyy-MM-dd") + ".log", DateTime.Now.ToString("HH:mm:ss") + ": " + ex.Message + "\n" + ex.ToString() + "\n");
return ex;
}
internal static Exception Display(this Exception ex, string msg = null, MessageBoxImage img = MessageBoxImage.Error)
{
MessageBox.Show(msg ?? ex.Message, "", MessageBoxButton.OK, img);
return ex;
}
Is it a known good practice to use a big try-catch per method in java?
For me, two try-catch blocks makes most methods too long. It obfuscates the intention if the method is doing many things.
With two try-catch blocks, it's doing at least four things, to be precise
- two cases for main flow (two try blocks)
- two cases for error handling
(catch blocks)
I would rather make short and clear methods out of each try-catch block- like
private String getHostNameFromConfigFile(String configFile, String defaultHostName) {
try {
BufferedReader reader = new BufferedReader(new FileReader(configFile));
return reader.readLine();
} catch (IOException e) {
return defaultHostName;
}
}
public Collection<String> readServerHostnames(File mainServerConfigFile, File backupServerConfigFile) {
String mainServerHostname=getHostNameFromConfigFile(mainServerConfigFile,"default- server.example.org");
String backupServerHostName=getHostNameFromConfigFile(backupServerConfigFile,"default- server.example.ru")
return Arrays.asList(mainServerHostname,backupServerHostName);
}
Robert C. Martin in 'Clean Code' takes it to next level, suggesting:
if the keyword 'try' exists in a function, it should be the very first word in the function and that there should be nothing after the catch/finally blocks.
I would definitely refactor the method with two separate try/catch blocks into smaller methods.
Is it best practice to try - catch my entire PHP code, or be as specific as possible?
generally throw locally, catch globally unless an exception handler is specific to a function in which case handle locally.
class fooException extends Exception{}
// DB CLASS
public function Open(){
// open DB connection
...
if ($this->Conn->connect_errno)
throw new fooException("Could not connect: " . $this->Conn->connect_error);
}
// MAIN CLASS
public final function Main(){
try{
// do stuff
}
catch(fooException $ex){
//handle fooExceptions
}
}
which is best practice to write to handle error handling then-catch or try-catch in javascript / node js
.catch()
vs. try/catch
is somewhat a personal preference and it also depends upon how you want the code to run. Usually, you would use try/catch
with await
and .catch()
when not using await
, but there are exceptions. Also, you would generally NOT use .then()
when using await
. The whole point of await
is to avoid .then()
and the nested code it causes.
Inside, your for
loop, await
without a .then()
vs. .then()
with await
gives completely different results. One offers parallel running of asynchronous operations, the other offers sequential running of asynchronous operations as the for
loop pauses until the await
fulfills.
So, you use the one that gives you the behavior you want. Then, pick the error handling method that matches (try/catch
with await
and .catch()
with .then()
- usually).
Best practice for Java exception handling
First, unless you have very good reason, never catch RuntimeException
, Exception
or Throwable
. These will catch most anything that is thrown, and Throwable
will catch everything, even those things you're not meant to catch, like OutOfMemoryError
.
Second, avoid catching runtime exceptions unless it directly impedes with the critical operation of your program. (But seriously, if anyone sees you catch a NullPointerException
, they are within their full rights to call you out on it.) The only exceptions you should be bothering with are those that you are required to handle. Out of your list of exceptions, the only one you should bother with is IOException
. The rest are the result of not enough tests, or sloppy coding; those shouldn't occur in the normal run time of your application.
Third, in Java 7, you have the ability to do a multi-catch statement for your exceptions, if the exceptions are mutually exclusive. The example linked does a good job of explaining it, but if you were to encounter code that threw both an IOException
and an SQLException
, you could handle it like this:
try {
// Dodgy database code here
catch (IOException|SQLException ex) {
logger.log(ex);
throw ex;
}
This cleans things up a bit, as you don't have unwieldy and huge chains of exceptions to catch.
is it good practice to use try inside try block to catch different errors? - JavaScript
By default a single try-catch block is enough without needs for nesting other try-catches into it. However, there may be some legitimate exceptions from these rules.
Exception 1: Different handlers for the same exception
Let's consider the following example
try {
myroutine(); // may throw three types of exceptions
} catch (e) {
if (e instanceof TypeError) {
// statements to handle TypeError exceptions
} else if (e instanceof RangeError) {
// statements to handle RangeError exceptions
} else if (e instanceof EvalError) {
// statements to handle EvalError exceptions
} else {
// statements to handle any unspecified exceptions
logMyErrors(e); // pass exception object to error handler
}
}
It is perfectly possible that inside your try
there is a section where a given error type, like a RangeError
needs a different way of handling than the main catch
. In this case it might make sense to have another try-catch inside your try, albeit, in this case, for better readability it would make sense to consider the inner try as a method and call that, so you would not physically nest the try-catch blocks, but separate the concerns of the try-catches into separate methods.
Exception 2: Handling a certain type of error only at a section of a try-block
It is quite possible that you want your try-catch to throw the error further in the majority of your try
block, but, in a specific section you want it to handle it. Again, in this case it would make sense to separate the inner try
into its own method.
Conclusion
Having nested try-catches are nonintuitive for a reader, therefore it makes sense to separate the inner try
into its own method whenever you encounter the need to nest tries. Yet, as the examples above show, there are legitimate needs to drift away from the outer handling of an error for some sections. However, by default it is a good idea to consider such sections as separate concerns worthy of separating from the method. Of course, sometimes you might want to keep nested try-catches without separating their concerns, but more often than not it is worth to apply the separations. So, a rule of thumb that you may want to consider is to refactor nested try-catches either into separate methods or a single try-catch, unless there is a very good reason not to do so.
Related Topics
How to I Catch Ssl Exceptions in a Mono Httplistener Server
Detect Windows Version in .Net
Why Isn't There Generic Variance for Classes in C# 4.0
Open Existing File, Append a Single Line
How to Change Datatype of a Datacolumn in a Datatable
How to Represent 0.1 in Floating Point Arithmetic and Decimal
Set Timeout for Webclient.Downloadfile()
Detecting Usb Drive Insertion and Removal Using Windows Service and C#
Copying from and to Clipboard Loses Image Transparency
{"<User Xmlns=''> Was Not Expected.} Deserializing Twitter Xml
How to Create a Navigation Menu in Dotnet Application
Load an Exe File and Run It from Memory
How to Bind a List to a Combobox
How to Apply Orderby on an Iqueryable Using a String Column Name Within a Generic Extension Method
Vb.Net Equivalent for C# 'Dynamic' with Option Strict On