ABAP_to_the_Future

There is no exception to the rule that every rule has an exception.
—James Thurber
7 Exception Classes and Design
by Contract
Most people have heard the phrase, “There are only two sure things in life: death
and taxes.” With computer programs, you can introduce another sure thing:
unexpected situations. Sure, you’d like the program flow to always follow the
happy path, on which everything proceeds according to the original design. However,
another common saying is, “No battle plan survives contact with the
enemy.” In real life, as soon as the prog ram is running, the user is going to type
in something unexpected, or an external system will send in something unexpected,
or one of a million possible other things will go wrong. These things are
referred to as exceptions.
To better understand what an exception really is, imagine a situation where you
have 100 monsters to be dispatched, and you ask the user how many he wants
every hour. Then, you divide 100 by the user input to see how long it will take to
dispatch all the monsters (e.g., 20 mons ters per hour = 100/20, meaning that it
takes five hours in total). Here are some possible exceptions:
왘 The user enters zero as the input value, leading to a division by zero dump.
왘 The user enters something like “hello” instead of a number.
왘 The user enters a correct value, but th en a database read on a configuration
table that you thought would always return a value doesn’t, because someone
accidently deleted the configuration table entries.
왘 A wombat chews through the underground cable, causing the user to lose his
connection to the SAP central instance.
왘 There’s a programming error in part of the program code, which only gets
triggered in rare circumstances (e.g., only when the user enters a value higher
255