Concepts of Program Design Type safety and exception handling Gabriele Keller Ron Vanderfeesten Overview higher & first-order syntax inference rules, induction tools to talk about languages abstract machines big step and small step operational semantics value & type environments parametric polymorphism/ generics type safety control stacks error/exception handling partial application/function closures semantic features functional (algebraic) data types static & dynamic static & dynamic scoping typing language concepts explicit & implicit procedural/imperative typing Types in programming languages statically vs dynamically typed type safe vs non type safe strongly vs weakly typed Static and Dynamic Semantics • MinHs is a type-safe (or strongly typed) language • What exactly do we mean by this? - these terms are used by different authors to mean different things - in general, it refers to guarantees about the run-time behaviour derived from static properties of the program - Robin Milner: “Well typed programs never go wrong” ‣ do not exhibit undefined behaviour - we define type safety to be the following two properties: ‣ preservation ‣ progress - we look at both preservation and progress in turn Preservation and Progress • Preservation: - Idea: evaluation does not change the type of an expression - Formally: If ⊢ e : τ and e ↦ e’ , then ⊢ e’ : τ • Progress: - Idea: a well-defined program can not get stuck - Formally: If e is well typed, then either e is a final state, or there exists e’, with e ↦ e’ e1 : τ ↦ e2 : τ ↦ e3 : τ ↦ … • Together is means that a program will either evaluate to a value of the promised type, or run forever Type Safety • For any language to be type safe, the progress and preservation properties need to hold! • Strictly speaking, the term type safety only makes sense in the context of a formal static and dynamic semantics • This is one reason why formal methods in programming languages are essential • The more expressive a type system is, the more information and assertions the type checker can derive at compile type - type systems usually should be decidable - but there are exceptions • MinHs is type safe - we can show that progress and preservation hold! - but what if the language contains partial operations, like division? Run-time Errors and Safety • Stuck states: in a type safe language language, stuck states correspond to ill- defined programs, e.g., - use (+) on values of function type, for example - treat an integer value as a pointer - use an integer as function let x = 1 in x 5 • Unsafe languages/operations do not get stuck - something happens, but its not predictable and/or portable: void boom () { void (f*)(void) = 0xdeadbeef; f (); } Type safe languages • Which of these languages are type safe? - C - C++ - C# - Haskell - Python - Rust Run-time Errors and Safety • How can we deal with partial functions, for example division by zero? Γ ⊢ t1 : Int Γ ⊢ t2 : Int Γ ⊢ Div t1 t2 : Int Problem: the expression 5/0 is well-typed, but does not evaluate to a value. • There are two alternatives: (1) Change static semantics: can we enhance the type system to check for division by zero? ‣ in general, such a type system would not be decidable ‣ there exist systems that approximate this (2) Change dynamic semantics: can we modify the semantics such that the devision by zero does not lead to a stuck state ‣ this approach is widely used for type safe languages Run-time Errors and Safety • Application of a partial function can yield Error Div v (Num 0) ↦ Error • An Error interrupts any computation Plus Error e ↦ Error Plus e Error ↦ Error If Error e1 e2 ↦ Error and so on..... Run-time errors and Safety • Typing the Error value: - a run-time error can have any type Γ ⊢ Error : ∀ τ. τ • What type of situations lead to checked run-time errors in Haskell? Exceptions • Error handling so far: - The Error expression to handle run-time errors deterministically aborts the whole program - For many applications, this is not the appropriate behaviour - Exceptions permit a more fine grained response to run-time errors • Error: - result of a programming error (e.g., preconditions of a function not met), can be fixed by fixing the program • Exception: - result of expected, but irregular occurrence, can possibly be handled in the program Exceptions in C# • Language constructs to handle exceptions: - try: execute a code block which may trigger an exception, has to be followed by at least one - catch block, which contains the exception handling code, which may be followed by a code block preceded by - finally, which is executed whether or not - throw, which triggers an exception, was called in the try block • Predefined exception classes contain: - Message: human readable text that describes the exception - StackTrace: lists all the called methods and line numbers • Exception class can be extended by user defined exceptions Exceptions in C# try { // code block which may trigger // an exception through … throw … } catch (ExceptionName e1 ) { // error handling code } catch (ExceptionName e2 ) { // error handling code } catch (ExceptionName eN ) { // error handling code } finally { // code block which will always be // executed } Exceptions in C# namespace SaveDivision { class Division { int result; Division() { result = 0; } public void div(int num1, int num2) { try { result = num1 / num2; } catch (DivideByZeroException e) { Console.WriteLine("Exception caught: {0}", e.Message); Console.WriteLine(“Stack trace: {0}", e.StackTrace); } finally { Console.WriteLine("Result: {0}", result); } } … } } Exceptions • Exceptions in MinHs: (1) raising (or throwing) an exception: raise e ‣ e : information about handling of exception (2) catching an exception: try e1 handle x => e2 ‣ catch expression raised in e1 ‣ exception handler is e2 ‣ access to information about handling exception via x Exceptions • Abstract Syntax ‣ raise e Raise e ‣ try e1 handle x => e2 Try e1 (x.e2) • Informal evaluation rules: on try e1 handle x => e2 ‣ evaluate e1, and ‣ if (Raise v) is encountered during e1, bind x to v and then evaluate e2 Exceptions • Example: try if (y <= 0) then raise -1 else x/y handle err => .... • try expressions can be nested ‣ innermost try expression catches ‣ handler may re-raise an exception Exceptions • Observations: - type of exception values (second argument of raise) • in many programming languages, this is a fixed type τexc • may simply be a string or integer (exception code) • e.g., subclass Throwable in Java, Exception in C# Exceptions - Static Semantics • Typing rules Γ ⊢ e : τexc Γ ⊢ Raise e: ∀ τ. τ Γ ∪ {x : τexc} ⊢ e2 :τ Γ ⊢ e1: τ Γ ⊢ Try e1, (x.e2): τ Exceptions - Dynamic Semantics • We introduce a new machines state s ⪻ (Raise v) the machine raises an exception with the exception value v • First approach: on s ⪻ (Raise v) ‣ propagate exception upwards in the control stack s ‣ use first handler encountered Exceptions - Dynamic Semantics • Entering a try block s ≻ Try e1(x.e2) ↦C (Try ☐ (x.e2) ▷ s)≻ e1 • Returning to a try block (Try ☐ (x.e2) ▷ s ≻ v1 ↦C s ≺ v1 • Evaluating a raise expression s ≻ Raise e ↦C (Raise ☐) ▷ s ≻ e • Raising an exception (Raise ☐) ▷s ≻ v ↦C s ⪻ Raise v • Catching an exception Try ☐ x.e2 ▷ s ⪻ Raise v ↦C s ≻ e2 [x:=v] • Propagating an exception f ▷ s ⪻ Raise v ↦C s ⪻ Raise v Exceptions - Dynamic Semantics • What is the problem here? - efficiency: the frames are popped one by one when an exception is raised • Second approach - how can we jump directly to the appropriate handler? - we use an extra handler stack h - a handler frame contains ‣ a copy of the control stack ‣ the handler expression Exceptions - Dynamic Semantics • Entering a try block (h, k) ≻ Try e1 (x.e2) ↦C (Handle k (x.e2) ▷ h,(Try ☐ )▷ k) ≻ e1 • Returning to a try block (Handle k (x.e2) ▷ h,(Try ☐) ▷ k) ≺ v1 ↦C (h, k) ≺ v1 • Evaluating a raise expression (h, k) ≻(Raise e) ↦C ( h, (Raise ☐) ▷ k) ≻ e • Raising an exception ( h, (Raise ☐) ▷ k) ≻ v ↦C (h, k) ⪻ (Raise v) • Catching an exception (handle k’ (x.e2))▷ h, k) ⪻ (Raise v) ↦C (h, k’) ≻ e2 [x:=v].