exception handling for information systems...christian-albrechts-university kiel, germany 1....
TRANSCRIPT
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
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 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
ExceptionsInformationSystems
Oct. 17, 2007
B. Thalheim
EverywhereException kinds
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
ExceptionsInformationSystems
Oct. 17, 2007
B. Thalheim
EverywhereException kinds
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
ExceptionsInformationSystems
Oct. 17, 2007
B. Thalheim
EverywhereException kinds
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
ExceptionsInformationSystems
Oct. 17, 2007
B. Thalheim
EverywhereException kinds
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
ExceptionsInformationSystems
Oct. 17, 2007
B. Thalheim
EverywhereException kinds
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
ExceptionsInformationSystems
Oct. 17, 2007
B. Thalheim
EverywhereException kinds
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
ExceptionsInformationSystems
Oct. 17, 2007
B. Thalheim
EverywhereException kinds
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
ExceptionsInformationSystems
Oct. 17, 2007
B. Thalheim
EverywhereException kinds
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
ExceptionsInformationSystems
Oct. 17, 2007
B. Thalheim
EverywhereException kinds
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
ExceptionsInformationSystems
Oct. 17, 2007
B. Thalheim
EverywhereException kinds
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
ExceptionsInformationSystems
Oct. 17, 2007
B. Thalheim
EverywhereException kinds
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
ExceptionsInformationSystems
Oct. 17, 2007
B. Thalheim
EverywhereException kinds
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
ExceptionsInformationSystems
Oct. 17, 2007
B. Thalheim
EverywhereException kinds
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
ExceptionsInformationSystems
Oct. 17, 2007
B. Thalheim
EverywhereException kinds
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
ExceptionsInformationSystems
Oct. 17, 2007
B. Thalheim
EverywhereException kinds
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
ExceptionsInformationSystems
Oct. 17, 2007
B. Thalheim
EverywhereException kinds
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
ExceptionsInformationSystems
Oct. 17, 2007
B. Thalheim
EverywhereException kinds
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
ExceptionsInformationSystems
Oct. 17, 2007
B. Thalheim
EverywhereException kinds
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
ExceptionsInformationSystems
Oct. 17, 2007
B. Thalheim
EverywhereException kinds
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
ExceptionsInformationSystems
Oct. 17, 2007
B. Thalheim
EverywhereException kinds
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)
Localization: registration department
Partiality: if Car ⊆ Cars With Dealer ...
Exception: Unknown Ownership
inclusion constraint with threshold θ
Car \ with Dealer[Car] ⊆θ Owned By[Car]
23
ExceptionsInformationSystems
Oct. 17, 2007
B. Thalheim
EverywhereException kinds
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)
Localization: registration department
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
ExceptionsInformationSystems
Oct. 17, 2007
B. Thalheim
EverywhereException kinds
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
ExceptionsInformationSystems
Oct. 17, 2007
B. Thalheim
EverywhereException kinds
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
ExceptionsInformationSystems
Oct. 17, 2007
B. Thalheim
EverywhereException kinds
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
ExceptionsInformationSystems
Oct. 17, 2007
B. Thalheim
EverywhereException kinds
Our scope
Specification
Processes
Monitors
Handlers
Finally
Concept Topic
Content
Information
c⃝B. Thalheim
Conjunction of two Signals
28
ExceptionsInformationSystems
Oct. 17, 2007
B. Thalheim
EverywhereException kinds
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
ExceptionsInformationSystems
Oct. 17, 2007
B. Thalheim
EverywhereException kinds
Our scope
Specification
Processes
Monitors
Handlers
Finally
Concept Topic
Content
Information
c⃝B. Thalheim
The Lifetime Process of a Car
30
ExceptionsInformationSystems
Oct. 17, 2007
B. Thalheim
EverywhereException kinds
Our scope
Specification
Processes
Monitors
Handlers
Finally
Concept Topic
Content
Information
c⃝B. Thalheim
Complete Set of Patterns for ExceptionHandling
31
ExceptionsInformationSystems
Oct. 17, 2007
B. Thalheim
EverywhereException kinds
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
ExceptionsInformationSystems
Oct. 17, 2007
B. Thalheim
EverywhereException kinds
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
ExceptionsInformationSystems
Oct. 17, 2007
B. Thalheim
EverywhereException kinds
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