Geek Answers Handbook

Is it right to catch every exception with the Exception class ??? If not, then what?

Is it right to catch every exception with the Exception class ??? If not, what should be the correct sequence to catch in the try catch block?

eg

try{ . . some code . } catch(Exception ex) { throw ex; }
+4
source share
5 answers

No, this is wrong.

  • Catching only to throw again is pointless.

  • Incorrect copying, resulting in loss of stack trace. The correct way to reverse (when retroning makes sense, that is) is simple: throw;

  • If you want to catch one exception and then throw another, you must save the first as an internal exception of the second. This is done by passing it to the constructor.

Bottom line: Use only those exceptions that you know what to do.

+15
source

If you select an exception immediately after catching it, it is essentially the same as having no try / catch block at all.

Eliminate certain exceptions that may occur.

For example, you are trying to save a file, but for some reason it cannot be written:

  try { SaveFile(); } catch(FileIsReadOnlyException) { //do whatever to recover } catch(Exception ex) { //If we hit the generic exception, we're saying that we basically have //no idea what went wrong, other than the save failed. // //Depending on the situation you might want to sink and log it, ie do nothing //but log it so you can debug and figure out what specific exception handler to //add to your code -- or you might want to try to save to a temporary file and //exit the program. // //If you were UpdatingAnAdvertisement() or doing something else non-critical //to the functioning of the program, you might just let it continue and //do nothing. // //In that case, you can just omit the generic catch. }
+6
source

In my opinion, you should usually try to catch the exceptions that you expect to get from the code that you call in the try block, and let the rest go to another place. For instance:

 try { // ... some code that you know may throw ArgumentException or any other known exceptions } catch (ArgumentException ex) { // ... handle the exception with a good idea of why it was thrown }

In the catch block, you can now handle the error in a clean, specific way, knowing that the invalid argument was passed somewhere in the try block. For example, you can warn the user that they provided an invalid argument.

If something happened that you did not expect (for example, a NullReferenceException), you probably do not know how to recover it, therefore, without catching it, you delegate responsibility to the consumer of your component in order to deal with exceptional situations in general.

In short, you should catch exceptions when you know how to handle or fix the error, and allow detection of unknown errors above call chains

Make sense?

+4
source

Always select the most specific exceptions first.

  try { // some file system code } catch (DirectoryNotFoundException e1) { // do something about it } catch (IOException e2) { // do something else about it } catch (Exception e) { // most generic catch - probably just dump onto screen or error log }

Re-creation is done to simplify debugging - this is not a way to inform the user about an error. The correct way to do this is:

  try { // some code that does X } catch (Exception e) { throw new Exception("describe X and parameters to it where applicable", e); }
+2
source

It is not that it is not true, because it is throwing an exception again - this is not what you should do. There are a lot of reasons that throw it around - it's a bad mojo, and they relate to things like maintainability, performance, and good coding techniques. Unfortunately, this allows the compiler.

As for when you should catch the exception, a good rule is that the exception should be caught at the point where you want your code to remove the exception.

+1
source

More articles:


All Articles