Skip to main content
Post Made Community Wiki by Joeri Sebrechts
deleted 97 characters in body
Source Link
Winston Ewert
  • 25.1k
  • 12
  • 76
  • 104

Reason to use exceptions:

  1. If you forget to catch an exceptional circumstance, your program will die and the stack trace will tell you exactly why. If you forget to handle the return value for an exception circumstance there is not telling how far away your program will exhibit incorrect behavior.
  2. Using return values only works if there is a sentinel value you can return. If all possible return values are already valid, what are you going to do?
  3. An exception will carry additional information about what happened which may be useful.

Reasons not to use exceptions:

  1. Many languages aren't designed to make exceptions fast.
  2. Exceptions which travel several layers up the stack can leave inconsistent state in their wake

My policyIn the end:

I use exception in two casesThe goal is to write code that might be considered flow controlcommunicates what is going on. I might catch an exception immediately after its thrownExceptions can help/hinder that depending on what the code is doing. For exampleA try/catch in python for a KeyError fromon a dictionary. The problems with exception don't really exhibit themeselves over such short distances.

The other case reference is when giving up on a more complex task, suchperfectly (as long as parsing command line arguments. I just put my complaint in an exception and throw ityou know the language) try/catch for the same KeyError five function layers away is dangerous.

Reason to use exceptions:

  1. If you forget to catch an exceptional circumstance, your program will die and the stack trace will tell you exactly why. If you forget to handle the return value for an exception circumstance there is not telling how far away your program will exhibit incorrect behavior.
  2. Using return values only works if there is a sentinel value you can return. If all possible return values are already valid, what are you going to do?
  3. An exception will carry additional information about what happened which may be useful.

Reasons not to use exceptions:

  1. Many languages aren't designed to make exceptions fast.
  2. Exceptions which travel several layers up the stack can leave inconsistent state in their wake

My policy:

I use exception in two cases that might be considered flow control. I might catch an exception immediately after its thrown. For example a KeyError from a dictionary. The problems with exception don't really exhibit themeselves over such short distances.

The other case is when giving up on a more complex task, such as parsing command line arguments. I just put my complaint in an exception and throw it.

Reason to use exceptions:

  1. If you forget to catch an exceptional circumstance, your program will die and the stack trace will tell you exactly why. If you forget to handle the return value for an exception circumstance there is not telling how far away your program will exhibit incorrect behavior.
  2. Using return values only works if there is a sentinel value you can return. If all possible return values are already valid, what are you going to do?
  3. An exception will carry additional information about what happened which may be useful.

Reasons not to use exceptions:

  1. Many languages aren't designed to make exceptions fast.
  2. Exceptions which travel several layers up the stack can leave inconsistent state in their wake

In the end:

The goal is to write code that communicates what is going on. Exceptions can help/hinder that depending on what the code is doing. A try/catch in python for a KeyError on a dictionary reference is perfectly (as long as you know the language) try/catch for the same KeyError five function layers away is dangerous.

Source Link
Winston Ewert
  • 25.1k
  • 12
  • 76
  • 104

Reason to use exceptions:

  1. If you forget to catch an exceptional circumstance, your program will die and the stack trace will tell you exactly why. If you forget to handle the return value for an exception circumstance there is not telling how far away your program will exhibit incorrect behavior.
  2. Using return values only works if there is a sentinel value you can return. If all possible return values are already valid, what are you going to do?
  3. An exception will carry additional information about what happened which may be useful.

Reasons not to use exceptions:

  1. Many languages aren't designed to make exceptions fast.
  2. Exceptions which travel several layers up the stack can leave inconsistent state in their wake

My policy:

I use exception in two cases that might be considered flow control. I might catch an exception immediately after its thrown. For example a KeyError from a dictionary. The problems with exception don't really exhibit themeselves over such short distances.

The other case is when giving up on a more complex task, such as parsing command line arguments. I just put my complaint in an exception and throw it.