1

For example, is it considered bad practice to write:

try
{
  #some code
}
catch (Exception e){
  #some code
}

Rather than 

try
{
  #some code
}
catch (ExceptionName e){  #like ArrayIndexOutOfBoundsException
  #some code
}

I guess the question holds for pretty much every language, be it Python, C++, Java...Any thoughts?

I am asking because it seems to me that you shouldn't, since it means you don't know what kind of error you are handling and what to do with it, but I see some people do it.

Barnabe
  • 488
  • 5
  • 18
  • 2
    It's certainly bad practice in Python... – mgilson Jun 19 '14 at 15:58
  • Depends on the context. – 101010 Jun 19 '14 at 16:00
  • 1
    It's bad practice. You always want the most specific exception type. – Anubian Noob Jun 19 '14 at 16:00
  • Both have uses, but the latter should be used a lot more frequently than the latter. – NPE Jun 19 '14 at 16:01
  • This question assumes that it doesn't matter what your exception handler does. What are you doing? That will tell you what you should be catching. – Drew Dormann Jun 19 '14 at 16:02
  • the latter should be used more frequently than the latter?? – Barnabe Jun 19 '14 at 16:02
  • 2
    This question, while interesting, is a bad fit for SO because it is too broad and subjective. http://programmers.stackexchange.com/ would be a better place to ask this. –  Jun 19 '14 at 16:04
  • agreed. It does not imply one single answer, but is more a question about good practices, what people think is right. If you tell me how to migrate it, I'll do. – Barnabe Jun 19 '14 at 16:08
  • @Barnabe - I have flagged the question and asked a moderator to migrate it. They will take it from here. :) –  Jun 19 '14 at 16:22

3 Answers3

2

YES!

There is a single exception to this:

You want to catch, do something, then re-throw. Maybe you have some resources you need to close before the exception goes up, or you want to inform the user something wrong has happened:

FileResource fileResource = new FileResource("/some/path");
try {
    fileResource.open();
    fileResource.dostuff();
    //other logic
} catch (Exception e){
    fileResource.close();
    throw e;
}

Hence, when an exception gets thrown, you can close your resources before the program exits.

Always catch the most specific exception type you can.

Also, catching all Exceptions is exceptionally bad in Python, because you can catch syntax exceptions and the like.

Nathan Merrill
  • 7,648
  • 5
  • 37
  • 56
  • If you can detail just a little bit more your example about catch-do-rethrow, it will be great. – Barnabe Jun 19 '14 at 16:13
  • Thanks for the edit. Crystal clear. – Barnabe Jun 19 '14 at 16:27
  • Shouldn't you use a `finally` block instead? And doesn't this lose information about where specifically the exception came from? – awksp Jun 19 '14 at 18:02
  • @user3580294: This is more of a language-agnostic question. For Java, yes, `finally` is probably a better better choice. Also, in Java, you don't lose any info this way (The stack trace is generated when you create a new Exception, not when you rethrow it) – Nathan Merrill Jun 19 '14 at 18:36
  • Ah, right, missed the other language tags. My mistake. Didn't realize that the stack trace was generated when the exception was created either. Thanks! – awksp Jun 19 '14 at 18:37
2

Not always, you'll want a graceful exit if your code fails if it's in production. So there's a good case for broader error handling.

def main():
    try:
        primary_process()
    except Exception as e: # Base error class that excludes keyboard interrupts
        logging.Error(e)   # and other things you don't want to catch.

But most of the time in your code you only handle as specific errors as you expect:

def something()
    part1() # don't expect the potential error to affect this, 
    part2() # so leave out of try block
    try:        # this infrequently raises an error for some reason, for now, 
        part3() # can't avoid. But we can handle if it happens.
    except LookupError as e: # specific error expected very infrequently
        handle(e)
    part4()

Another relevant Q&A: Why is "except: pass" a bad programming practice?

Community
  • 1
  • 1
Russia Must Remove Putin
  • 374,368
  • 89
  • 403
  • 331
  • Yeah, I just saw that one, it is a great answer as well, thanks a lot for the link, and also for your answer, it is completely clear, I really feel I learnt something today. – Barnabe Jun 19 '14 at 16:29
1

Yes. It is always a good practice to know exactly what type of exception you are catching because it helps in better handling

Vivin
  • 1,327
  • 2
  • 9
  • 28
  • If you should always know exactly what type of exception you are catching, then shouldn't you just handle this is a more graceful way other than catching the exception? (See Aaron Hall's answer). – Dave Doknjas Jun 19 '14 at 16:51
  • You cannot always know about all the exceptions for example runtime time exceptions. But you should handle all other exceptions which you think your try can throw so that you can have a better idea of what went wrong. Also you can still catch exceptions of type Exception after it missed all your specific exceptions, so that you can end gracefully.Ex: try{ //some code} catch(SomeException1 s1){ // } catch(SomeException2 s2){ // } catch(Exception s3) { ///end gracefully } – Vivin Jun 19 '14 at 16:55