====== User Defined Exception ======
[[dido:public:ra:xapend:xapend.a_glossary:start| Return to Glossary ]]

A **User Defined Exception** is an [[dido:public:ra:xapend:xapend.a_glossary:e:exception]] designed by the system engineers to occur during runtime to reflect aberrant conditions that arise during execution, often preventing other more generic runtime conditions such as [[dido:public:ra:xapend:xapend.a_glossary:o:overflow]], 
[[dido:public:ra:xapend:xapend.a_glossary:w:wrap_around]], 
[[dido:public:ra:xapend:xapend.a_glossary:u:underflow]], 
[[dido:public:ra:xapend:xapend.a_glossary:d:division_by_zero]] etc. The **User Defined Exceptions** typically provide specific diagnostic messages to help during later forensic analysis of logs. In the following example, interests are checked until n interest rate greater than 20%, and when they are, the Usury exception is raised.


<Code cpp linenum:1>
#include <iostream>
#include <exception>
using namespace std;

class Usury : public exception
{ int _interestRate;
  public :
    const char* explaination()
    { return "Usury Interest Rate detected";
    } // End explaination
}; // End Exception Usury
   
int main()
{ float interestRate = 0;
  try
  { while(1)
    { interestRate+=interestRate+.5;
      if ( interestRate >= 20.0 )
      { Usury usery;
    	throw usery;
      } // End interestRate usery check
      cout << "Interest Rate: " << interestRate <<endl;
    } // End while loop
  } // End try block
  catch ( Usury _usuryException )
  { cout  interestRate << " interest "<<  ex.explaination();
  } // End catch block
  return 0;
} // End main routine
</Code>

When these occur, the system catches the error and a **User Defined Exception** is raised.

Deciding whether to use an **User Defined Exception** to or a return values for [[dido:public:ra:xapend:xapend.a_glossary:c:control_flow]] is a balance of several "forces":

  * The caller can ignore a return value and continue with the next line, but the caller can not ignore an Exception. Exceptions tend to be used in cases where ignoring the problem and continuing could lead to a bigger problem.
  * Exceptions impose a burden because it requires the caller to provide specific code to handle the exceptional behavior rather than just checking a return value. Since there is no way to check if the return code is checked or acted upon by the calling routine, the return code basically becomes optional and should be the decision producer of the code
  * However, Exceptions relieve the immediate caller of the burden of checking the result since when Exceptions are raised, the [[dido:public:ra:xapend:xapend.a_glossary:s:stack_memory]] is unwound
  * As a general rule, Exception handling is more complex than using ordinary return codes and Control Flow, so if the **User Defined Exceptions** are thrown often there is a performance hit when thrown frequently. 
  * Exceptions are better when the design required a return code to be more than just a simple integer (e.g., making the method return Object so that it can return either a string or a number).


Source: [[ dido:public:ra | Defined by the DIDO Reference Architecture]]


/**=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
/* To add a discussion page to this page, comment out the line that says 
  ~~DISCUSSION:off~~
*/
~~DISCUSSION:on|Outstanding Issues~~
~~DISCUSSION:off~~