Exception Handling For Information Systems...Christian-Albrechts-University Kiel, Germany 1. Exceptions Information Systems Oct. 17, 2007 B. Thalheim Everywhere ... Foundation of decisions

0.5 setgray00.5 setgray0.250.5 setgray0.50.5 setgray0.750.5 setgray1

0.5 setgray0 0.5 setgray0.25 0.5 setgray0.5 0.5 setgray0.75 0.5 setgray1

Exception HandlingFor Information Systems

RCDLPereslavl-Zaleskij

Oct. 17, 2007

Alfs T. Berztiss and Bernhard ThalheimUniversity of Pittsburgh, USA

Christian-Albrechts-University Kiel, Germany

1

ExceptionsInformationSystems

Oct. 17, 2007

B. Thalheim

EverywhereException kinds

Our scope

Specification

Processes

Monitors

Handlers

Finally

Concept Topic

Content

Information

c⃝B. Thalheim

An ExampleCar Registration

�

?

-owned by

6

-with dealer

Person Car

Dealer Co.

(0,n) 2(0,n)

3(1,n)

from

[to]

Type ofownership

Contract

�

InsuranceCo.

?

-insured

(1, 1)

Is this complete?

2


Oct. 17, 2007

B. Thalheim


Our scope

Specification

Processes

Monitors

Handlers

Finally

Concept Topic

Content

Information

c⃝B. Thalheim

An ExampleCar Registration

�

?

-owned by

6

-with dealer

Person Car

Dealer Co.

(0, n) 2(0, n)

3(1, n)

from

[to]

Type of

ownershipContract

�

Insurance

Co.

?

-insured

(1, 1)

Unregistered cars

Insurance problems

Owners existence

We finally obtain an EER schema with around 70 entity and relationship

types

3


Oct. 17, 2007

B. Thalheim


Our scope

Specification

Processes

Monitors

Handlers

Finally

Concept Topic

Content

Information

c⃝B. Thalheim

Exceptions in Programming Languages

Error conditions

Unforeseen events

Tracking and controlling

Treatment

typically parameter-less, name-less, with local variables, sequence of

statements

Call of an error handling procedure

implicit by the controller or explicit call (raise, try-catch)

Dissemination of exceptions

similar to execution of subprogrammes with potential return

4


Oct. 17, 2007

B. Thalheim


Our scope

Specification

Processes

Monitors

Handlers

Finally

Concept Topic

Content

Information

c⃝B. Thalheim

Exceptions in Programming LanguagesObject-Based Languages

at the end of each programming unit:

named rules for exception handling

predefined exceptions

implicit call through operation or explicit call through statement (raise)

upward inheritance until program unit has defined exception

after completion of exception: control back to calling unit

Assertions and assurance based on contracts

(Eiffel, C++ makros)

Exception injection from superclasses

the nightmare of Java programming

Functional languages

explicit definition of exception

activation through raise

computation through handle with pattern and execution expression

5


Oct. 17, 2007

B. Thalheim


Our scope

Specification

Processes

Monitors

Handlers

Finally

Concept Topic

Content

Information

c⃝B. Thalheim

Kinds of Exceptions

Exceptions caused by errors: operation errors, design errors, organiza-

tional errors, hardware errors

explicit error treatment

recovery management based on explicit specification of errors

Exceptions caused by randomness or non-determinancy: appear and

vanish at any point of time

cannot be eliminated not described

extensions of recovery management?

Exceptions caused by incompleteness: modeling, specification incom-

plete due to complexity, limitations of languages and abilities

robust system specification?

Exceptions as systems flexibility: exceptions as ‘normal’ states or ‘nor-

mal’ reactions

exception handler: exceptional situations and correct treatment

6


Oct. 17, 2007

B. Thalheim


Our scope

Specification

Processes

Monitors

Handlers

Finally

Concept Topic

Content

Information

c⃝B. Thalheim

Occurrence of ExceptionsIncompleteness

of specifications as “modeling gap”

Reasons, causes Possible resolutionincomplete knowledge negated specifications

incomplete coverage robust specifications

macrodata modeling redesign to microdata

inability to represent approximative specifications

7


Oct. 17, 2007

B. Thalheim


Our scope

Specification

Processes

Monitors

Handlers

Finally

Concept Topic

Content

Information

c⃝B. Thalheim

The Modeling Gap

Modality

“Partial reality”

Exactness Confidence

6

?

Usage oftheory

Foundation ofdecisions

Modeler

6

?

actswithin

Context

6

Modelingdecision

� URevisionduring the

development process

6 6

Things ofreality Predicator

Partof reality

“Topic”�

6

-Observedproperty

�

?

underusage

Referencemodel

“Schema” as resultand partial point of view

of a databasedevelopment process

8


Oct. 17, 2007

B. Thalheim


Our scope

Specification

Processes

Monitors

Handlers

Finally

Concept Topic

Content

Information

c⃝B. Thalheim

Occurrence of ExceptionsInsufficiency

to represent the current knowledge

Reasons, causes Possible resolutionimplementation restrictions extending by theories and lan-

guages

conceptual language restrictions novel theories, advanced logics

restricted attention of devel-

opers

� scope of reference models

non-axiomatizabilty change of logics

locality of reasoning interference reasoning

9


Oct. 17, 2007

B. Thalheim


Our scope

Specification

Processes

Monitors

Handlers

Finally

Concept Topic

Content

Information

c⃝B. Thalheim

Occurrence of ExceptionsDynamic changes over time

due to evolution

Reasons, causes Possible resolutionchange-sensitive normalization change of normal form

time overload and mingling separate TA, user, validity time

non-temporal types temporal types

too restrictive models flexibility

instability of schema dynamic schemata

temporary runtime error similar to 9 kinds of nulls

10


Oct. 17, 2007

B. Thalheim


Our scope

Specification

Processes

Monitors

Handlers

Finally

Concept Topic

Content

Information

c⃝B. Thalheim

Occurrence of ExceptionsHidden cases

due to limiting to “normal case”

Reasons, causes Possible resolutionpragmatic assumptions explicit modeling

hidden assumptions iterative testing

self-restrictions detection of reasons

restricted scope of users education, sharpening

overlooked cases analysis, verification

11


Oct. 17, 2007

B. Thalheim


Our scope

Specification

Processes

Monitors

Handlers

Finally

Concept Topic

Content

Information

c⃝B. Thalheim

InsufficiencyTreatment of concurrent actions and overcoming locality

(mapping to atomic constraint cases)

Introduction of specific default values for exceptional cases in domainsdates misspelled, wrong, not according rules, doubtful

specialization of types for treatment of exceptions

Measuring incompleteness of specification, implementation etc.correctness of schema #correct types

#types

completeness of schema #represented concepts#application world concepts

capability #conflict−free types among application world concepts#types among application world concepts

exception of various types: (e.g. correctness)incorrectness of type systemincorrectness of constructor systemincorrectness of structuringincorrectness of static semantics

Introduction of robust schema partstolerance and distance to error measuresaccuracy and confidence

12


Oct. 17, 2007

B. Thalheim


Our scope

Specification

Processes

Monitors

Handlers

Finally

Concept Topic

Content

Information

c⃝B. Thalheim

Dynamic changesChange of normal form

separation of robust and changing parts within schemataseparation of strong and soft constraintsintroduction of “almost valid” constraints

Explicit introduction of time domainsTA, user, validity timeexplicit monitoring of environment

Temporal typesexplicit volatile types (temporary tables)explicit virtual types

Flexibilityrobust schemata

Dynamic schemataintroduction of an explicit semantics statestate management similar to TA management

13


Oct. 17, 2007

B. Thalheim


Our scope

Specification

Processes

Monitors

Handlers

Finally

Concept Topic

Content

Information

c⃝B. Thalheim

Hidden casesDetection of assumptions

development and programming culturemaking restrictions explicitAI or mining of developers and programmers behavior

Iterative modellingrobustness propertiesexplicit change and version management

Detection of reasons for self-restriction

Broadening the scopeof developersabstract programming

Control and correction of completeness problemsdevelopment of completeness criteriaanalysis and verification toolspredictability of correctness and exceptions

14


Oct. 17, 2007

B. Thalheim


Our scope

Specification

Processes

Monitors

Handlers

Finally

Concept Topic

Content

Information

c⃝B. Thalheim

Restricting the Scope of Research

Integrity constraint globalisation through globalisation graphs

Integrity constraint handlers with resumption, termination, ex-

plicit treatment of status of exceptions, basic primitives, control

structures, and specific invocation

management of explicit and derived exceptions

Integrity violation patching as small “repairing” action (locally,

partially, nested?)

Embedding into Oracle PL/SQL facilities as reference imple-

mentation proposal

Abstract specification through ASM framework with cor-

rectness and completeness properties and refinement

15


Oct. 17, 2007

B. Thalheim


Our scope

Specification

Processes

Monitors

Handlers

Finally

Concept Topic

Content

Information

c⃝B. Thalheim

Constraint Maintenance System

Type specification with constraints, with scoping of constraints

extension of current framework for anticipating and preparing

States of integrity constraints as a state diagram

explicit treatment of constraint context (type environment), their

propagation

explicit invalidation detection query

first: restricted class of constraints

without soft constraints

Operation set for treatment of violations with precondition and

postcondition operations

Integrity manager monitoring static properties (successful operati-

on) and dynamic properties

detection of probably inconsistent parts of the database

ability for diagnosing,resolving exceptions

treatment of exception conformance (consistency) and composition

16


Oct. 17, 2007

B. Thalheim


Our scope

Specification

Processes

Monitors

Handlers

Finally

Concept Topic

Content

Information

c⃝B. Thalheim

Elementary Exception Case Specification

Exception referential integrity failure after update in referenced table

For Event update in referenced table

Definition (DB |= R[X ] ⊆ S [Y ]) ∧ (upd(DB, S, Y) ̸|= R[X ] ⊆ S [Y ])

Critically availability of referencing table

Anticipated pro-

cesses

cascading

Detection pro-

cesses

checking availability

Avoidance pro-

cesses

locking referencing table and channel or deriving a re-

trying/resumption model

Resolution pro-

cesses

call exception handler “cascade2” or “retry3”

17


Oct. 17, 2007

B. Thalheim


Our scope

Specification

Processes

Monitors

Handlers

Finally

Concept Topic

Content

Information

c⃝B. Thalheim

Elementary Exception Case Specification

Exception handler cascade2: cascading an action throughout scope

Definition optain lock(R); upd(DB,R,select Y as X from S

where Y = :change)

Precondition update scheduled on parent table

Overhead locking on child table

Misleading positives update blocked in child table

Best for direct push of an update

18


Oct. 17, 2007

B. Thalheim


Our scope

Specification

Processes

Monitors

Handlers

Finally

Concept Topic

Content

Information

c⃝B. Thalheim

Integrity Constraint SpecificationIntegrity Constraint φ

[Localization: < unit name> ]

[Partiality: < validity condition >]

[Exception: < exception condition >]

[In-Context: < enforcement rule, time, granularity >]

[Out-Context: < conditional operation, accept on >] .

(Local and global) integrity constraints (environment and behavior)

static dynamic

struc-tural

seman-tical

represen-tationconstr.

developmentconstr.

transitionconstr.

temporal

� j

? j� � R q

19


Oct. 17, 2007

B. Thalheim


Our scope

Specification

Processes

Monitors

Handlers

Finally

Concept Topic

Content

Information

c⃝B. Thalheim

Constraint Graphs through VisualSQL

EingeschriebenIn

Stud.MatrNr ◦Program ◦Von

Bis

char[7]

char[20]

date

date check ( Bis > Von )

Student

MatrNr ◦Name ( ◦)

Gebdatum ( ◦)

char[7]

char[40]

date

�(1,.): (iStud =C,dEing =R,

uStud =R,uEing =R)

(.,2): (iEing =R,uStud =C,uEing =R)

(1) Computing constraint environment

(2) Case-base reasoning techniques for graph completion

(3) Derivation of deontic covers within each case

20


Oct. 17, 2007

B. Thalheim


Our scope

Specification

Processes

Monitors

Handlers

Finally

Concept Topic

Content

Information

c⃝B. Thalheim

Enforcement of Integrity ConstraintSpecification

Direct enforcement through declarative constraints with RESTRICT,

NO ACTION, CASCADE, SET VALUE (null, default),

[INITIALLY] DEFERRED, [INITIALLY] IMMEDIATE [DEFERABLE]

Transactions with three mechanisms on failure:

(1) rollback on inconsistency currently exclusive treatment

(2) erasing effects of TA:

transaction COMPENSATED ON FAILURE BY transaction

(3) raising an exception:

transaction CONTINGENTED ON EXCEPTION BY exception

Triggers with the after-before activation time, row-statement granu-

larity,

1-n (SQL:1999, DB2, Informix, SQL Server) , n-1 (Sybase) or n-n (Ingres,Oracle) event-

trigger pairs

21


Oct. 17, 2007

B. Thalheim


Our scope

Specification

Processes

Monitors

Handlers

Finally

Concept Topic

Content

Information

c⃝B. Thalheim

Exception Specification in Oracle PL/SQL

Declaration Section: Deklaration (names,...) of user-defined exceptionsDECLARE exception EXCEPTION

Exception Section: Definition of actions raised in case of appearanceof an exceptionWHEN exception THEN pl/sql-statement;WHEN OTHERS THEN pl/sql-statement;

Exceptions can be called at arbitrary places in PL/SQL blocks through RAISEIF condition THEN RAISE exception

Execution sequence

- call of an exception

- execution of corresponding actions in WHEN-clauses

- stop of execution in the calling block (e.g., continuation inanonymous blocks)

CREATE OR REPLACE TRIGGER forbidden action at evening

BEFORE DELETE ON System Table

BEGIN IF TO CHAR(SYSDATE,’HH24:MI’) BETWEEN ’18:00’ AND ’22:00’

THEN RAISE APPLICATION ERROR (-20101,’Wer zu spaet kommt, den ...’);

END IF;

END;

22


Oct. 17, 2007

B. Thalheim


Our scope

Specification

Processes

Monitors

Handlers

Finally

Concept Topic

Content

Information

c⃝B. Thalheim

Exception Specification for the Example

Normal case:

Car Must Be Owned By Person card(Owned By, Car) = (1,n)

Localization: registration department

inclusion constraint Car ⊆ Owned By[Car]

Extended Case:

Car Must Be Owned By Person card(Owned By, Car) = (1,n)


Partiality: if Car ⊆ Cars With Dealer ...

Exception: Unknown Ownership

inclusion constraint with threshold θ

Car \ with Dealer[Car] ⊆θ Owned By[Car]

23


Oct. 17, 2007

B. Thalheim


Our scope

Specification

Processes

Monitors

Handlers

Finally

Concept Topic

Content

Information

c⃝B. Thalheim

Exception Policies for the ExampleCar Must Be Owned By Person card(Owned By, Car) = (1,n)


Partiality: if Car ⊆ Cars With Dealer ...

Policy:

On Insert(x) Into Car If x ̸∈ owned by[Car]Do Insert Into owned by Immediately

On Delete(x) From CarDo Delete (.x) From owned by Immediately

On Update(x) On CarDo Cascade Update On owned by Immediately

On Insert(x) Into owned by If x.Car ̸∈ CarDo No Action Deferred

On Delete(x) From owned by If card(σCar=x .Car (owned by)) = 1Do Restrict Immediately

On Update(x) On owned byDo No Action Immediately

On Delete(x) From Person If x ∈ owned by [Person]Do No Action Deferred

On Update(x) On Person If x ∈ owned by [Person]Do Cascade Deferred

24


Oct. 17, 2007

B. Thalheim


Our scope

Specification

Processes

Monitors

Handlers

Finally

Concept Topic

Content

Information

c⃝B. Thalheim

Exceptions and Processes

ACTION Example;

@(p) ON(SigA(a,b)) IN(0,q) EXCEPTION(ExA) ::

DELAY(x,y) EXCEPTION(ExB):

(TrA(a,b), TrB(b));

ENDACTION

1. <Action>::= ACTION [<ActionId>];

<Activator>:: [<ActPart>;]*

ENDACTION

2. <Activator>::= ON<Sig> | ON(<Sig> [,<Sig>]+)OFF <TPart> |

@<TPart> [ON(<Sig>) [<EPart>] |

ON(<Sig>)IN <TPart>]

3. <TPart>::= (<TimeExp> [,<TimeExp>]) [<EPart>]

4. <Sig>::= <SigId> [(<Exp> [,<Exp>]*)]

5. <EPart>::= EXCEPTION(<PrimAct>)

6. <ActPart>::= [<Delay>]

[<PrimAct> | (<PrimAct> [,<PrimAct>]*)]+

7. <Delay>::= DELAY <TPart> [<EPart>]:

25


Oct. 17, 2007

B. Thalheim


Our scope

Specification

Processes

Monitors

Handlers

Finally

Concept Topic

Content

Information

c⃝B. Thalheim

Exceptions and ProcessesASM specificationuniverse: signal, action, timePointmonitored functions: Clock, Signalshared functions: stateAction(a), stateTA(ta)rules: Exception(exc)

ActionReactionTimeObserver(a, eV , s, sReact , iReact , excVal , excReact ,TA) =

if Clock = p and time(a) = p then stateAction(a) := active

if stateAction(a) = active and time(s) ∈ [time(a), time(a) + p]

and Clock ∈ [time(a), time(a) + p]

then stateAction(a) := receivedSignal

if stateAction(a) = active and time(s) > time(a) + p and Clock > time(a) + p

then Exception(excVal) par stateAction(a) = interrupt

if stateAction(a) = receivedSignal and Clock = time(s) + sReact

thenforall ta ∈ TAstateTA(ta) := enabled

if (forall ta ∈ TA stateTA(ta) = enabled)

and Clock = time(s) + sReact + iReact + 1

then (forall ta ∈ TAstateTA(ta) = abort) par Exception(excReact)

for a(ction), e(nd)V (alidity), s(ignal), s(tart)React(ion),

i(ntervall)React(ion), exc(eption)Val(idity), exc(eption)React(ion),TA)

26


Oct. 17, 2007

B. Thalheim


Our scope

Specification

Processes

Monitors

Handlers

Finally

Concept Topic

Content

Information

c⃝B. Thalheim

Exceptions and ProcessesASM specificationuniverse: signal, action, timePointmonitored functions: Clock, Signalshared functions: stateAction(a), stateTA(ta)rules: Exception(exc)

ActionReactionTimeObserver(a, eV , s, sReact , iReact , excVal , excReact ,TA) =

if Clock = p and time(a) = p then stateAction(a) := active

if stateAction(a) = active and time(s) ∈ [time(a), time(a) + p]

and Clock ∈ [time(a), time(a) + p]

then stateAction(a) := receivedSignal

if stateAction(a) = active and time(s) > time(a) + p and Clock > time(a) + p

then Exception(excVal) par stateAction(a) = interrupt

if stateAction(a) = receivedSignal and Clock = time(s) + sReact

thenforall ta ∈ TAstateTA(ta) := enabled

if (forall ta ∈ TA stateTA(ta) = enabled) and Clock = time(s) + sReact + iReact + 1

then (forall ta ∈ TAstateTA(ta) = abort) par Exception(excReact)

for a(ction), e(nd)V (alidity), s(ignal), s(tart)React(ion), i(ntervall)React(ion),exc(eption)Val(idity), exc(eption)React(ion),TA)

27


Oct. 17, 2007

B. Thalheim


Our scope

Specification

Processes

Monitors

Handlers

Finally

Concept Topic

Content

Information

c⃝B. Thalheim

Conjunction of two Signals

28


Oct. 17, 2007

B. Thalheim


Our scope

Specification

Processes

Monitors

Handlers

Finally

Concept Topic

Content

Information

c⃝B. Thalheim

Handling of Processes: ContinuingExample by a Net of an Action

29


Oct. 17, 2007

B. Thalheim


Our scope

Specification

Processes

Monitors

Handlers

Finally

Concept Topic

Content

Information

c⃝B. Thalheim

The Lifetime Process of a Car

30


Oct. 17, 2007

B. Thalheim


Our scope

Specification

Processes

Monitors

Handlers

Finally

Concept Topic

Content

Information

c⃝B. Thalheim

Complete Set of Patterns for ExceptionHandling

31


Oct. 17, 2007

B. Thalheim


Our scope

Specification

Processes

Monitors

Handlers

Finally

Concept Topic

Content

Information

c⃝B. Thalheim

Exception Specification for the Example

ACTION Insurance;

ON Sig(CarX ) ::

DELAY(0, Limit) EXCEPTION(HandlerA):

Insure(CarX );

ENDACTIONActionReactionTimeObserver(Insurance, limit , signalInsureCar(x ),HandlerA,

∞,⊥, Insure(carX ))

ACTION LeaseReturn;

ON Leased(CarY ) ::

DELAY(0, Leaseperiod) EXCEPTION(Late):

Return(CarY );

ENDACTIONActionReactionTimeObserver(LeaseReturn, leasePeriod , signalLeasedcarX ,Late,

∞,⊥,Return(carX ))

32


Oct. 17, 2007

B. Thalheim


Our scope

Specification

Processes

Monitors

Handlers

Finally

Concept Topic

Content

Information

c⃝B. Thalheim

State Chart of an Exception Handler

Processmonitor

- Exceptionmanifestation

6

6

Exceptionreasoner

- Raisedexception

?SpecificEH plans

?SelectedEH plan

?

Actions usingadvanced stored procedures

?Exceptiondetection

Map tocase-basedformulas

Collectpossibilities

Instantiatesolution

Pick EHplan

Execute EHplan

33


Oct. 17, 2007

B. Thalheim


Our scope

Specification

Processes

Monitors

Handlers

Finally

Concept Topic

Content

Information

c⃝B. Thalheim

ConcludingGeneral model for exception specification, handling and monitoring

both for TA’s and processes

Five main pattern for exceptions

This paper: based on signals/events

Open issues

hierarchically structured exception sets

general monitors

tracers and detectors

exceptions of exceptions

34

Documents

Exception Handling For Information Systems...Christian-Albrechts-University Kiel, Germany 1. Exceptions Information Systems Oct. 17, 2007 B. Thalheim Everywhere ... Foundation of decisions