SlideShare a Scribd company logo

Railway Oriented Programming

Scott Wlaschin, profile picture
Scott Wlaschin

The document presents the concept of Railway Oriented Programming (ROP) as a functional approach to error handling in programming, primarily using F#. It contrasts traditional imperative programming error handling with functional programming techniques, emphasizing the use of a dual track model where errors can be managed more elegantly. The document covers principles of composing functions, handling errors through a 'two-track' model, and improving software design by making use of type-safe error handling.

Technology
1 of 154
Downloaded 1,009 times
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
Most read
128
129
130
131
132
133
134
135
136
137
138
Most read
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
Most read
Railway Oriented Programming A functional approach to error handling What do railways have to do with programming?
Railway Oriented Programming A functional approach to error handling Scott Wlaschin @ScottWlaschin fsharpforfunandprofit.com FPbridge.co.uk...but OCaml and Haskell are very similar. Examples will be in F#...
Overview Topics covered: • Happy path programming • Straying from the happy path • Introducing "Railway Oriented Programming" • Using the model in practice • Extending and improving the design
Happy path programming Implementing a simple use case
A simple use case Receive request Validate and canonicalize request Update existing user record Send verification email Return result to user type Request = { userId: int; name: string; email: string } "As a user I want to update my name and email address"
Imperative code string ExecuteUseCase() { var request = receiveRequest(); validateRequest(request); canonicalizeEmail(request); db.updateDbFromRequest(request); smtpServer.sendEmail(request.Email); return "Success"; }
Functional flow let executeUseCase = receiveRequest >> validateRequest >> canonicalizeEmail >> updateDbFromRequest >> sendEmail >> returnMessage F# left-to-right composition operator
Straying from the happy path... What do you do when something goes wrong?
Straying from the happy path
“A program is a spell cast over a computer, turning input into error messages”
“A program is a spell cast over a computer, turning input into error messages”
Straying from the happy path Name is blank Email not valid Receive request Validate and canonicalize request Update existing user record Send verification email Return result to user User not found Db error Authorization error Timeout "As a user I want to update my name and email address" type Request = { userId: int; name: string; email: string } - and see sensible error messages when something goes wrong!
Imperative code with error handling string UpdateCustomerWithErrorHandling() { var request = receiveRequest(); validateRequest(request); canonicalizeEmail(request); db.updateDbFromRequest(request); smtpServer.sendEmail(request.Email) return "OK"; }
Imperative code with error handling string UpdateCustomerWithErrorHandling() { var request = receiveRequest(); var isValidated = validateRequest(request); if (!isValidated) { return "Request is not valid" } canonicalizeEmail(request); db.updateDbFromRequest(request); smtpServer.sendEmail(request.Email) return "OK"; }
Imperative code with error handling string UpdateCustomerWithErrorHandling() { var request = receiveRequest(); var isValidated = validateRequest(request); if (!isValidated) { return "Request is not valid" } canonicalizeEmail(request); var result = db.updateDbFromRequest(request); if (!result) { return "Customer record not found" } smtpServer.sendEmail(request.Email) return "OK"; }
Imperative code with error handling string UpdateCustomerWithErrorHandling() { var request = receiveRequest(); var isValidated = validateRequest(request); if (!isValidated) { return "Request is not valid" } canonicalizeEmail(request); try { var result = db.updateDbFromRequest(request); if (!result) { return "Customer record not found" } } catch { return "DB error: Customer record not updated" } smtpServer.sendEmail(request.Email) return "OK"; }
Imperative code with error handling string UpdateCustomerWithErrorHandling() { var request = receiveRequest(); var isValidated = validateRequest(request); if (!isValidated) { return "Request is not valid" } canonicalizeEmail(request); try { var result = db.updateDbFromRequest(request); if (!result) { return "Customer record not found" } } catch { return "DB error: Customer record not updated" } if (!smtpServer.sendEmail(request.Email)) { log.Error "Customer email not sent" } return "OK"; }
Imperative code with error handling string UpdateCustomerWithErrorHandling() { var request = receiveRequest(); var isValidated = validateRequest(request); if (!isValidated) { return "Request is not valid" } canonicalizeEmail(request); try { var result = db.updateDbFromRequest(request); if (!result) { return "Customer record not found" } } catch { return "DB error: Customer record not updated" } if (!smtpServer.sendEmail(request.Email)) { log.Error "Customer email not sent" } return "OK"; }
Functional flow with error handling let updateCustomer = receiveRequest >> validateRequest >> canonicalizeEmail >> updateDbFromRequest >> sendEmail >> returnMessage Before
Functional flow with error handling let updateCustomerWithErrorHandling = receiveRequest >> validateRequest >> canonicalizeEmail >> updateDbFromRequest >> sendEmail >> returnMessage Does this look familiar? Don't believe me? Stay tuned! After
Designing the unhappy path
Request/response (non-functional) design Request Response Validate Update Send Request handling service Request Response Validate Update Send Request handling service Request Errors Response Validate Update Send Request handling service Imperative code can return early
Data flow (functional) design ResponseValidate Update SendA single function representing the use caseRequest Request ResponseValidate Update Send A single function representing the use case Request Errors Success Response Validate Update Send Error Response A single function representing the use case Q: How can you bypass downstream functions when an error happens?
Functional design How can a function have more than one output? type Result = | Success | ValidationError | UpdateError | SmtpError Request Errors SuccessValidate Update Send Failure A single function representing the use case
Functional design How can a function have more than one output? type Result = | Success | Failure Request Errors SuccessValidate Update Send Failure A single function representing the use case
Functional design How can a function have more than one output? type Result<'TEntity> = | Success of 'TEntity | Failure of string Request Errors SuccessValidate Update Send Failure A single function representing the use case
Functional design Request Errors SuccessValidate Update Send Failure A single function representing the use case • Each use case will be equivalent to a single function • The function will return a sum type with two cases: "Success" and "Failure". • The use case function will be built from a series of smaller functions, each representing one step in a data flow. • The errors from each step will be combined into a single "failure" path.
How do I work with errors in a functional way?
Monad dialog
Railway Oriented Programming
Railway Oriented Programming
Railway Oriented Programming
Railway Oriented Programming
Railway Oriented Programming
Railway Oriented Programming
Railway Oriented Programming
Railway Oriented Programming
Railway Oriented Programming
Railway Oriented Programming
Railway Oriented Programming
Railway Oriented Programming
Railway Oriented Programming
Railway Oriented Programming
Railway Oriented Programming
Railway Oriented Programming
Railway Oriented Programming
Railway Oriented Programming
v
Railway Oriented Programming
Railway Oriented Programming
Railway Oriented Programming
Railway Oriented Programming
Railway Oriented Programming
Railway Oriented Programming
Railway Oriented Programming
Railway Oriented Programming
Railway Oriented Programming
Railway Oriented Programming
Railway Oriented Programming
Railway Oriented Programming
Railway Oriented Programming
Railway Oriented Programming
Railway Oriented Programming
Monads are confusing? Monads are not really that confusing http://bit.ly/monad-paper
Railway oriented programming This has absolutely nothing to do with monads.
A railway track analogy The Tunnel of Transformation Function apple -> banana
A railway track analogy Function 1 apple -> banana Function 2 banana -> cherry
A railway track analogy >> Function 1 apple -> banana Function 2 banana -> cherry
A railway track analogy New Function apple -> cherry Can't tell it was built from smaller functions!
An error generating function Request SuccessValidate Failure let validateInput input = if input.name = "" then Failure "Name must not be blank" else if input.email = "" then Failure "Email must not be blank" else Success input // happy path
Introducing switches Success! Failure Input ->
Connecting switches Validate UpdateDbon success bypass
Connecting switches Validate UpdateDb
Connecting switches Validate UpdateDb SendEmail
Connecting switches Validate UpdateDb SendEmail
The two-track model in practice
Composing switches Validate UpdateDb SendEmail
Composing switches Validate UpdateDb SendEmail
Composing switches Validate UpdateDb SendEmail >> >> Composing one-track functions is fine...
Composing switches Validate UpdateDb SendEmail >> >> ... and composing two-track functions is fine...
Composing switches Validate UpdateDb SendEmail   ... but composing switches is not allowed!
Composing switches Validate Two-track input Two-track input Validate One-track input Two-track input  
Building an adapter block Two-track input Slot for switch function Two-track output
Building an adapter block Two-track input Two-track output Validate Validate
let adapt switchFunction = fun twoTrackInput -> match twoTrackInput with | Success s -> switchFunction s | Failure f -> Failure f Building an adapter block Two-track input Two-track output
let adapt switchFunction = fun twoTrackInput -> match twoTrackInput with | Success s -> switchFunction s | Failure f -> Failure f Building an adapter block Two-track input Two-track output
let adapt switchFunction = fun twoTrackInput -> match twoTrackInput with | Success s -> switchFunction s | Failure f -> Failure f Building an adapter block Two-track input Two-track output
let adapt switchFunction = fun twoTrackInput -> match twoTrackInput with | Success s -> switchFunction s | Failure f -> Failure f Building an adapter block Two-track input Two-track output
Bind as an adapter block Two-track input Two-track output let bind switchFunction = fun twoTrackInput -> match twoTrackInput with | Success s -> switchFunction s | Failure f -> Failure f bind : ('a -> TwoTrack<'b>) -> TwoTrack<'a> -> TwoTrack<'b>
Bind as an adapter block Two-track input Two-track output let bind switchFunction twoTrackInput = match twoTrackInput with | Success s -> switchFunction s | Failure f -> Failure f bind : ('a -> TwoTrack<'b>) -> TwoTrack<'a> -> TwoTrack<'b>
name50 Bind example let nameNotBlank input = if input.name = "" then Failure "Name must not be blank" else Success input let name50 input = if input.name.Length > 50 then Failure "Name must not be longer than 50 chars" else Success input let emailNotBlank input = if input.email = "" then Failure "Email must not be blank" else Success input nameNotBlank emailNotBlank
Bind example nameNotBlank (combined with) name50 (combined with) emailNotBlank nameNotBlank name50 emailNotBlank
Bind example bind nameNotBlank bind name50 bind emailNotBlank nameNotBlank name50 emailNotBlank
Bind example bind nameNotBlank >> bind name50 >> bind emailNotBlank nameNotBlank name50 emailNotBlank
Bind example let validateRequest = bind nameNotBlank >> bind name50 >> bind emailNotBlank // validateRequest : TwoTrack<Request> -> TwoTrack<Request> validateRequest
Bind example let (>>=) twoTrackInput switchFunction = bind switchFunction twoTrackInput let validateRequest twoTrackInput = twoTrackInput >>= nameNotBlank >>= name50 >>= emailNotBlank validateRequest
Bind doesn't stop transformations FunctionB type TwoTrack<'TEntity> = | Success of 'TEntity | Failure of string FunctionA
Composing switches - review Validate UpdateDb SendEmail Validate UpdateDb SendEmail
Comic Interlude What do you call a train that eats toffee? I don't know, what do you call a train that eats toffee? A chew, chew train!
More fun with railway tracks... Working with other functions
More fun with railway tracks... Fitting other functions into this framework: • Single track functions • Dead-end functions • Functions that throw exceptions • Supervisory functions
Converting one-track functions Fitting other functions into this framework: • Single track functions • Dead-end functions • Functions that throw exceptions • Supervisory functions
Converting one-track functions // trim spaces and lowercase let canonicalizeEmail input = { input with email = input.email.Trim().ToLower() } canonicalizeEmail
Converting one-track functions UpdateDb SendEmailValidate canonicalizeEmail Won't compose
Converting one-track functions Two-track input Slot for one-track function Two-track output
Converting one-track functions Two-track input Two-track output CanonicalizeCanonicalize
Converting one-track functions Two-track input Two-track output let map singleTrackFunction = fun twoTrackInput -> match twoTrackInput with | Success s -> Success (singleTrackFunction s) | Failure f -> Failure f map : ('a -> 'b) -> TwoTrack<'a> -> TwoTrack<'b>` Single track function
Converting one-track functions Two-track input Two-track output let map singleTrackFunction = bind (singleTrackFunction >> Success) map : ('a -> 'b) -> TwoTrack<'a> -> TwoTrack<'b> Single track function
Converting one-track functions UpdateDb SendEmailValidate canonicalizeEmail Will compose
Converting dead-end functions Fitting other functions into this framework: • Single track functions • Dead-end functions • Functions that throw exceptions • Supervisory functions
Converting dead-end functions let updateDb request = // do something // return nothing at all updateDb
Converting dead-end functions SendEmailValidate UpdateDb Won't compose
Converting dead-end functions One-track input Slot for dead end function One-track output
Converting dead-end functions One-track input One-track output let tee deadEndFunction oneTrackInput = deadEndFunction oneTrackInput oneTrackInput tee : ('a -> unit) -> 'a -> 'a Dead end function
Converting dead-end functions SendEmailValidate UpdateDb Will compose
Functions that throw exceptions Fitting other functions into this framework: • Single track functions • Dead-end functions • Functions that throw exceptions • Supervisory functions
Functions that throw exceptions One-track input Two-track output SendEmail SendEmail Add try/catch to handle timeouts, say Looks innocent, but might throw an exception
Functions that throw exceptions EvenYoda recommends not to use exception handling for control flow: Guideline: Convert exceptions into Failures "Do or do not, there is no try".
Supervisory functions Fitting other functions into this framework: • Single track functions • Dead-end functions • Functions that throw exceptions • Supervisory functions
Supervisory functions Two-track input Two-track output Slot for one-track function for Success case Slot for one-track function for Failure case
Putting it all together
Putting it all together Validate UpdateDb SendEmail Canonicalize Input Output??
Putting it all together Validate UpdateDb SendEmail Canonicalize returnMessage Input Output let returnMessage result = match result with | Success obj -> OK obj.ToJson() | Failure msg -> BadRequest msg
Putting it all together - review The "two-track" framework is a useful approach for most use-cases. You can fit most functions into this model.
Putting it all together - review The "two-track" framework is a useful approach for most use-cases. let updateCustomer = receiveRequest >> validateRequest >> updateDbFromRequest >> sendEmail >> returnMessage let updateCustomer = receiveRequest >> validateRequest >> updateDbFromRequest >> sendEmail >> returnMessage Let's look at the code -- before and after adding error handling
Comic Interlude Why can't a steam locomotive sit down? I don't know, why can't a steam locomotive sit down? Because it has a tender behind!
Extending the framework: • Designing for errors • Parallel tracks • Domain events
Designing for errors Unhappy paths are requirements too
Designing for errors let validateInput input = if input.name = "" then Failure "Name must not be blank" else if input.email = "" then Failure "Email must not be blank" else Success input // happy path type TwoTrack<'TEntity> = | Success of 'TEntity | Failure of string Using strings is not good
Designing for errors let validateInput input = if input.name = "" then Failure NameMustNotBeBlank else if input.email = "" then Failure EmailMustNotBeBlank else Success input // happy path type TwoTrack<'TEntity> = | Success of 'TEntity | Failure of ErrorMessage type ErrorMessage = | NameMustNotBeBlank | EmailMustNotBeBlank Special type rather than string
Designing for errors let validateInput input = if input.name = "" then Failure NameMustNotBeBlank else if input.email = "" then Failure EmailMustNotBeBlank else if (input.email doesn't match regex) then Failure EmailNotValid input.email else Success input // happy path type ErrorMessage = | NameMustNotBeBlank | EmailMustNotBeBlank | EmailNotValid of EmailAddress Add invalid email as data
Designing for errors type ErrorMessage = | NameMustNotBeBlank | EmailMustNotBeBlank | EmailNotValid of EmailAddress // database errors | UserIdNotValid of UserId | DbUserNotFoundError of UserId | DbTimeout of ConnectionString | DbConcurrencyError | DbAuthorizationError of ConnectionString * Credentials // SMTP errors | SmtpTimeout of SmtpConnection | SmtpBadRecipient of EmailAddress Documentation of everything that can go wrong -- And it's type-safe documentation that can't go out of date!
Designing for errors type ErrorMessage = | NameMustNotBeBlank | EmailMustNotBeBlank | EmailNotValid of EmailAddress // database errors | UserIdNotValid of UserId | DbUserNotFoundError of UserId | DbTimeout of ConnectionString | DbConcurrencyError | DbAuthorizationError of ConnectionString * Credentials // SMTP errors | SmtpTimeout of SmtpConnection | SmtpBadRecipient of EmailAddress Documentation of everything that can go wrong -- And it's type-safe documentation that can't go out of date! As we develop the code, we can build up a complete list of everything that could go wrong
Designing for errors – converting to strings No longer works – each case must now be explicitly converted to a string returnMessage let returnMessage result = match result with | Success _ -> "Success" | Failure msg -> msg
Designing for errors – converting to strings let returnMessage result = match result with | Success _ -> "Success" | Failure err -> match err with | NameMustNotBeBlank -> "Name must not be blank" | EmailMustNotBeBlank -> "Email must not be blank" | EmailNotValid (EmailAddress email) -> sprintf "Email %s is not valid" email // database errors | UserIdNotValid (UserId id) -> sprintf "User id %i is not a valid user id" id | DbUserNotFoundError (UserId id) -> sprintf "User id %i was not found in the database" id | DbTimeout (_,TimeoutMs ms) -> sprintf "Could not connect to database within %i ms" ms | DbConcurrencyError -> sprintf "Another user has modified the record. Please resubmit" | DbAuthorizationError _ -> sprintf "You do not have permission to access the database" // SMTP errors | SmtpTimeout (_,TimeoutMs ms) -> sprintf "Could not connect to SMTP server within %i ms" ms | SmtpBadRecipient (EmailAddress email) -> sprintf "The email %s is not a valid recipient" email Each case must be converted to a string – but this is only needed once, and only at the last step. All strings are in one place, so translations are easier. returnMessage (or use resource file)
Designing for errors - review type ErrorMessage = | NameMustNotBeBlank | EmailMustNotBeBlank | EmailNotValid of EmailAddress // database errors | UserIdNotValid of UserId | DbUserNotFoundError of UserId | DbTimeout of ConnectionString | DbConcurrencyError | DbAuthorizationError of ConnectionString * Credentials // SMTP errors | SmtpTimeout of SmtpConnection | SmtpBadRecipient of EmailAddress Documentation of everything that can go wrong. Type-safe -- can't go out of date!
Parallel tracks
Parallel validation nameNotBlank name50 emailNotBlank Problem: Validation done in series. So only one error at a time is returned
Parallel validation nameNotBlank name50 emailNotBlank Split input Combine output Now we do get all errors at once! ... But how to combine?
Combining switches + Trick: if we create an operation that combines pairs into a new switch, we can repeat to combine as many switches as we like.
Combining switches + + Trick: if we create an operation that combines pairs into a new switch, we can repeat to combine as many switches as we like.
Combining switches + + Trick: if we create an operation that combines pairs into a new switch, we can repeat to combine as many switches as we like.
Domain events Communicating information to downstream functions
Events are not errors Validate UpdateDb SendEmail Tell CRM that email was sent
Events are not errors Validate UpdateDb SendEmail Tell CRM that email was sent type MyUseCaseMessage = | NameMustNotBeBlank | EmailMustNotBeBlank | EmailNotValid of EmailAddress // database errors | UserIdNotValid of UserId // SMTP errors | SmtpTimeout of SmtpConnection // Domain events | UserSaved of AuditInfo | EmailSent of EmailAddress * MsgId
Events are not errors Validate UpdateDb SendEmail Tell CRM that email was sent type MyUseCaseMessage = | NameMustNotBeBlank | EmailMustNotBeBlank | EmailNotValid of EmailAddress // database errors | UserIdNotValid of UserId // SMTP errors | SmtpTimeout of SmtpConnection // Domain events | UserSaved of AuditInfo | EmailSent of EmailAddress * MsgId type TwoTrack<'TEntity> = | Success of 'TEntity * Message list | Failure of Message list
Comic Interlude Why can't a train driver be electrocuted? I don't know, why can't a train driver be electrocuted? Because he's not a conductor!
Some topics not covered... ... but could be handled in an obvious way.
Topics not covered • Errors across service boundaries • Async on success path (instead of sync) • Compensating transactions (instead of two phase commit) • Logging (tracing, app events, etc.)
Summary A recipe for handling errors in a functional way
Recipe for handling errors in a functional way type TwoTrack<'TEntity> = | Success of 'TEntity * Message list | Failure of Message list Validate UpdateDb SendEmail type Message = | NameMustNotBeBlank | EmailMustNotBeBlank | EmailNotValid of EmailAddress
Demo http://bit.ly/rop-example
I don’t always have errors...
I don’t always have errors... Railway Oriented Programming @ScottWlaschin fsharpforfunandprofit.com FPbridge.co.uk http://bit.ly/rop-example

More Related Content

PDF
Functional Design Patterns (DevTernity 2018)
Scott Wlaschin
 
PDF
Pipeline oriented programming
Scott Wlaschin
 
PDF
Domain Modeling with FP (DDD Europe 2020)
Scott Wlaschin
 
PDF
Functional Domain Modeling - The ZIO 2 Way
Debasish Ghosh
 
PPTX
SOLID - Principles of Object Oriented Design
Riccardo Cardin
 
PDF
Building confidence in concurrent code with a model checker: TLA+ for program...
Scott Wlaschin
 
PPTX
Capabilities for Resources and Effects
Martin Odersky
 
PDF
Functional Programming Patterns (NDC London 2014)
Scott Wlaschin
 
Functional Design Patterns (DevTernity 2018)
Scott Wlaschin
 
Pipeline oriented programming
Scott Wlaschin
 
Domain Modeling with FP (DDD Europe 2020)
Scott Wlaschin
 
Functional Domain Modeling - The ZIO 2 Way
Debasish Ghosh
 
SOLID - Principles of Object Oriented Design
Riccardo Cardin
 
Building confidence in concurrent code with a model checker: TLA+ for program...
Scott Wlaschin
 
Capabilities for Resources and Effects
Martin Odersky
 
Functional Programming Patterns (NDC London 2014)
Scott Wlaschin
 

What's hot (20)

PDF
The Power of Composition (NDC Oslo 2020)
Scott Wlaschin
 
PDF
Domain Driven Design with the F# type System -- NDC London 2013
Scott Wlaschin
 
PDF
Domain Driven Design with the F# type System -- F#unctional Londoners 2014
Scott Wlaschin
 
PDF
Reinventing the Transaction Script (NDC London 2020)
Scott Wlaschin
 
PDF
Domain Modeling Made Functional (DevTernity 2022)
Scott Wlaschin
 
PDF
The Power of Composition
Scott Wlaschin
 
PDF
Functional Programming Patterns (BuildStuff '14)
Scott Wlaschin
 
PDF
The Functional Programmer's Toolkit (NDC London 2019)
Scott Wlaschin
 
PDF
Dr Frankenfunctor and the Monadster
Scott Wlaschin
 
PDF
Clean code
Arturo Herrero
 
PDF
Towards Functional Programming through Hexagonal Architecture
CodelyTV
 
PDF
Let's make a contract: the art of designing a Java API
Mario Fusco
 
PDF
Extensible Data Modeling
Karwin Software Solutions LLC
 
PDF
The Functional Programming Toolkit (NDC Oslo 2019)
Scott Wlaschin
 
PDF
Real Life Clean Architecture
Mattia Battiston
 
PDF
SDC 3rd 최흥배님 - Boost.multi_index 사용하기
OnGameServer
 
PDF
Declarative UIs with Jetpack Compose
Ramon Ribeiro Rabello
 
PDF
Pragmatic functional refactoring with java 8
RichardWarburton
 
PDF
Functional Programming 101 with Scala and ZIO @FunctionalWorld
Jorge Vásquez
 
PDF
Sum and Product Types - The Fruit Salad & Fruit Snack Example - From F# to Ha...
Philip Schwarz
 
The Power of Composition (NDC Oslo 2020)
Scott Wlaschin
 
Domain Driven Design with the F# type System -- NDC London 2013
Scott Wlaschin
 
Domain Driven Design with the F# type System -- F#unctional Londoners 2014
Scott Wlaschin
 
Reinventing the Transaction Script (NDC London 2020)
Scott Wlaschin
 
Domain Modeling Made Functional (DevTernity 2022)
Scott Wlaschin
 
The Power of Composition
Scott Wlaschin
 
Functional Programming Patterns (BuildStuff '14)
Scott Wlaschin
 
The Functional Programmer's Toolkit (NDC London 2019)
Scott Wlaschin
 
Dr Frankenfunctor and the Monadster
Scott Wlaschin
 
Clean code
Arturo Herrero
 
Towards Functional Programming through Hexagonal Architecture
CodelyTV
 
Let's make a contract: the art of designing a Java API
Mario Fusco
 
Extensible Data Modeling
Karwin Software Solutions LLC
 
The Functional Programming Toolkit (NDC Oslo 2019)
Scott Wlaschin
 
Real Life Clean Architecture
Mattia Battiston
 
SDC 3rd 최흥배님 - Boost.multi_index 사용하기
OnGameServer
 
Declarative UIs with Jetpack Compose
Ramon Ribeiro Rabello
 
Pragmatic functional refactoring with java 8
RichardWarburton
 
Functional Programming 101 with Scala and ZIO @FunctionalWorld
Jorge Vásquez
 
Sum and Product Types - The Fruit Salad & Fruit Snack Example - From F# to Ha...
Philip Schwarz
 
Ad

Similar to Railway Oriented Programming (20)

PPTX
Railway Orientated Programming In C#
Tama000
 
ODP
Functional programming
S M Asaduzzaman
 
PPSX
Functional patterns and techniques in C#
Péter Takács
 
PPTX
Functional Programming in Swift
Saugat Gautam
 
PDF
Антон Молдован "Type driven development with f#"
Fwdays
 
PDF
Beyond PITS, Functional Principles for Software Architecture
Jayaram Sankaranarayanan
 
PDF
Functional Programming 101 for Java 7 Developers
Jayaram Sankaranarayanan
 
PDF
Functional Programming for Busy Object Oriented Programmers
Diego Freniche Brito
 
PDF
Fun with functions
Frank Müller
 
PPTX
Столпы функционального программирования для адептов ООП, Николай Мозговой
Sigma Software
 
PDF
Functional Swift
Geison Goes
 
PDF
Think sharp, write swift
Pascal Batty
 
PDF
Elm: give it a try
Eugene Zharkov
 
PDF
Workshop Swift
Commit University
 
PPTX
Shipping Pseudocode to Production VarnaLab
Dobromir Nikolov
 
PDF
The Trailblazer Ride from the If Jungle into a Civilised Railway Station - Or...
Ruby Meditation
 
PDF
Dnipro conf
BotondOrbn
 
PPTX
Grokking Techtalk #37: Software design and refactoring
Grokking VN
 
PDF
Swift Programming Language
Giuseppe Arici
 
PDF
Cocoa heads 09112017
Vincent Pradeilles
 
Railway Orientated Programming In C#
Tama000
 
Functional programming
S M Asaduzzaman
 
Functional patterns and techniques in C#
Péter Takács
 
Functional Programming in Swift
Saugat Gautam
 
Антон Молдован "Type driven development with f#"
Fwdays
 
Beyond PITS, Functional Principles for Software Architecture
Jayaram Sankaranarayanan
 
Functional Programming 101 for Java 7 Developers
Jayaram Sankaranarayanan
 
Functional Programming for Busy Object Oriented Programmers
Diego Freniche Brito
 
Fun with functions
Frank Müller
 
Столпы функционального программирования для адептов ООП, Николай Мозговой
Sigma Software
 
Functional Swift
Geison Goes
 
Think sharp, write swift
Pascal Batty
 
Elm: give it a try
Eugene Zharkov
 
Workshop Swift
Commit University
 
Shipping Pseudocode to Production VarnaLab
Dobromir Nikolov
 
The Trailblazer Ride from the If Jungle into a Civilised Railway Station - Or...
Ruby Meditation
 
Dnipro conf
BotondOrbn
 
Grokking Techtalk #37: Software design and refactoring
Grokking VN
 
Swift Programming Language
Giuseppe Arici
 
Cocoa heads 09112017
Vincent Pradeilles
 
Ad

More from Scott Wlaschin (14)

PDF
The lazy programmer's guide to writing thousands of tests
Scott Wlaschin
 
PDF
The Power Of Composition (DotNext 2019)
Scott Wlaschin
 
PDF
Domain Modeling Made Functional (KanDDDinsky 2019)
Scott Wlaschin
 
PDF
Four Languages From Forty Years Ago (NewCrafts 2019)
Scott Wlaschin
 
PDF
Four Languages From Forty Years Ago
Scott Wlaschin
 
PDF
F# for C# Programmers
Scott Wlaschin
 
PDF
Designing with capabilities (DDD-EU 2017)
Scott Wlaschin
 
PDF
Thirteen ways of looking at a turtle
Scott Wlaschin
 
PDF
Designing with Capabilities
Scott Wlaschin
 
PDF
Enterprise Tic-Tac-Toe
Scott Wlaschin
 
PDF
An introduction to property based testing
Scott Wlaschin
 
PDF
Swift vs. Language X
Scott Wlaschin
 
PDF
Doge-driven design
Scott Wlaschin
 
PDF
The Theory of Chains
Scott Wlaschin
 
The lazy programmer's guide to writing thousands of tests
Scott Wlaschin
 
The Power Of Composition (DotNext 2019)
Scott Wlaschin
 
Domain Modeling Made Functional (KanDDDinsky 2019)
Scott Wlaschin
 
Four Languages From Forty Years Ago (NewCrafts 2019)
Scott Wlaschin
 
Four Languages From Forty Years Ago
Scott Wlaschin
 
F# for C# Programmers
Scott Wlaschin
 
Designing with capabilities (DDD-EU 2017)
Scott Wlaschin
 
Thirteen ways of looking at a turtle
Scott Wlaschin
 
Designing with Capabilities
Scott Wlaschin
 
Enterprise Tic-Tac-Toe
Scott Wlaschin
 
An introduction to property based testing
Scott Wlaschin
 
Swift vs. Language X
Scott Wlaschin
 
Doge-driven design
Scott Wlaschin
 
The Theory of Chains
Scott Wlaschin
 

Recently uploaded (20)

PDF
Dropbox Q2 2025 Financial Results & Investor Presentation
Dropbox
 
PDF
Network Security Unit 5.pdf for BCA BBA.
Serpent6
 
PDF
Building Integrated photovoltaic BIPV_UPV.pdf
SandeepSingh286037
 
PPTX
Digital-Transformation-Roadmap-for-Companies.pptx
David Malick Dieng
 
PDF
Advanced methodologies resolving dimensionality complications for autism neur...
IAESIJAI
 
PDF
Spectral efficient network and resource selection model in 5G networks
IAESIJAI
 
PPTX
SOPHOS-XG Firewall Administrator PPT.pptx
AgnesMunisi
 
PPTX
Spectroscopy.pptx food analysis technology
nawahassan45
 
PPTX
KOM of Painting work and Equipment Insulation REV00 update 25-dec.pptx
muhammadmuneebnaeem7
 
PDF
Video forgery: An extensive analysis of inter-and intra-frame manipulation al...
IAESIJAI
 
PPTX
Programs and apps: productivity, graphics, security and other tools
4mqw9zch22
 
PPTX
Tartificialntelligence_presentation.pptx
ry7r52mzb4
 
PDF
Reach Out and Touch Someone: Haptics and Empathic Computing
Mark Billinghurst
 
PDF
Blue Purple Modern Animated Computer Science Presentation.pdf.pdf
Akar16
 
PPT
Teaching material agriculture food technology
LiaRayya
 
PDF
Machine learning based COVID-19 study performance prediction
IAESIJAI
 
PDF
Empathic Computing: Creating Shared Understanding
Mark Billinghurst
 
PPTX
Machine Learning_overview_presentation.pptx
kondavamsidharreddy2
 
PDF
Optimiser vos workloads AI/ML sur Amazon EC2 et AWS Graviton
Julien SIMON
 
PDF
cuic standard and advanced reporting.pdf
SimoneTitaniumTomase
 
Dropbox Q2 2025 Financial Results & Investor Presentation
Dropbox
 
Network Security Unit 5.pdf for BCA BBA.
Serpent6
 
Building Integrated photovoltaic BIPV_UPV.pdf
SandeepSingh286037
 
Digital-Transformation-Roadmap-for-Companies.pptx
David Malick Dieng
 
Advanced methodologies resolving dimensionality complications for autism neur...
IAESIJAI
 
Spectral efficient network and resource selection model in 5G networks
IAESIJAI
 
SOPHOS-XG Firewall Administrator PPT.pptx
AgnesMunisi
 
Spectroscopy.pptx food analysis technology
nawahassan45
 
KOM of Painting work and Equipment Insulation REV00 update 25-dec.pptx
muhammadmuneebnaeem7
 
Video forgery: An extensive analysis of inter-and intra-frame manipulation al...
IAESIJAI
 
Programs and apps: productivity, graphics, security and other tools
4mqw9zch22
 
Tartificialntelligence_presentation.pptx
ry7r52mzb4
 
Reach Out and Touch Someone: Haptics and Empathic Computing
Mark Billinghurst
 
Blue Purple Modern Animated Computer Science Presentation.pdf.pdf
Akar16
 
Teaching material agriculture food technology
LiaRayya
 
Machine learning based COVID-19 study performance prediction
IAESIJAI
 
Empathic Computing: Creating Shared Understanding
Mark Billinghurst
 
Machine Learning_overview_presentation.pptx
kondavamsidharreddy2
 
Optimiser vos workloads AI/ML sur Amazon EC2 et AWS Graviton
Julien SIMON
 
cuic standard and advanced reporting.pdf
SimoneTitaniumTomase
 

Railway Oriented Programming

  • 1. Railway Oriented Programming A functional approach to error handling What do railways have to do with programming?
  • 2. Railway Oriented Programming A functional approach to error handling Scott Wlaschin @ScottWlaschin fsharpforfunandprofit.com FPbridge.co.uk...but OCaml and Haskell are very similar. Examples will be in F#...
  • 3. Overview Topics covered: • Happy path programming • Straying from the happy path • Introducing "Railway Oriented Programming" • Using the model in practice • Extending and improving the design
  • 5. A simple use case Receive request Validate and canonicalize request Update existing user record Send verification email Return result to user type Request = { userId: int; name: string; email: string } "As a user I want to update my name and email address"
  • 6. Imperative code string ExecuteUseCase() { var request = receiveRequest(); validateRequest(request); canonicalizeEmail(request); db.updateDbFromRequest(request); smtpServer.sendEmail(request.Email); return "Success"; }
  • 7. Functional flow let executeUseCase = receiveRequest >> validateRequest >> canonicalizeEmail >> updateDbFromRequest >> sendEmail >> returnMessage F# left-to-right composition operator
  • 8. Straying from the happy path... What do you do when something goes wrong?
  • 9. Straying from the happy path
  • 10. “A program is a spell cast over a computer, turning input into error messages”
  • 11. “A program is a spell cast over a computer, turning input into error messages”
  • 12. Straying from the happy path Name is blank Email not valid Receive request Validate and canonicalize request Update existing user record Send verification email Return result to user User not found Db error Authorization error Timeout "As a user I want to update my name and email address" type Request = { userId: int; name: string; email: string } - and see sensible error messages when something goes wrong!
  • 13. Imperative code with error handling string UpdateCustomerWithErrorHandling() { var request = receiveRequest(); validateRequest(request); canonicalizeEmail(request); db.updateDbFromRequest(request); smtpServer.sendEmail(request.Email) return "OK"; }
  • 14. Imperative code with error handling string UpdateCustomerWithErrorHandling() { var request = receiveRequest(); var isValidated = validateRequest(request); if (!isValidated) { return "Request is not valid" } canonicalizeEmail(request); db.updateDbFromRequest(request); smtpServer.sendEmail(request.Email) return "OK"; }
  • 15. Imperative code with error handling string UpdateCustomerWithErrorHandling() { var request = receiveRequest(); var isValidated = validateRequest(request); if (!isValidated) { return "Request is not valid" } canonicalizeEmail(request); var result = db.updateDbFromRequest(request); if (!result) { return "Customer record not found" } smtpServer.sendEmail(request.Email) return "OK"; }
  • 16. Imperative code with error handling string UpdateCustomerWithErrorHandling() { var request = receiveRequest(); var isValidated = validateRequest(request); if (!isValidated) { return "Request is not valid" } canonicalizeEmail(request); try { var result = db.updateDbFromRequest(request); if (!result) { return "Customer record not found" } } catch { return "DB error: Customer record not updated" } smtpServer.sendEmail(request.Email) return "OK"; }
  • 17. Imperative code with error handling string UpdateCustomerWithErrorHandling() { var request = receiveRequest(); var isValidated = validateRequest(request); if (!isValidated) { return "Request is not valid" } canonicalizeEmail(request); try { var result = db.updateDbFromRequest(request); if (!result) { return "Customer record not found" } } catch { return "DB error: Customer record not updated" } if (!smtpServer.sendEmail(request.Email)) { log.Error "Customer email not sent" } return "OK"; }
  • 18. Imperative code with error handling string UpdateCustomerWithErrorHandling() { var request = receiveRequest(); var isValidated = validateRequest(request); if (!isValidated) { return "Request is not valid" } canonicalizeEmail(request); try { var result = db.updateDbFromRequest(request); if (!result) { return "Customer record not found" } } catch { return "DB error: Customer record not updated" } if (!smtpServer.sendEmail(request.Email)) { log.Error "Customer email not sent" } return "OK"; }
  • 19. Functional flow with error handling let updateCustomer = receiveRequest >> validateRequest >> canonicalizeEmail >> updateDbFromRequest >> sendEmail >> returnMessage Before
  • 20. Functional flow with error handling let updateCustomerWithErrorHandling = receiveRequest >> validateRequest >> canonicalizeEmail >> updateDbFromRequest >> sendEmail >> returnMessage Does this look familiar? Don't believe me? Stay tuned! After
  • 22. Request/response (non-functional) design Request Response Validate Update Send Request handling service Request Response Validate Update Send Request handling service Request Errors Response Validate Update Send Request handling service Imperative code can return early
  • 23. Data flow (functional) design ResponseValidate Update SendA single function representing the use caseRequest Request ResponseValidate Update Send A single function representing the use case Request Errors Success Response Validate Update Send Error Response A single function representing the use case Q: How can you bypass downstream functions when an error happens?
  • 24. Functional design How can a function have more than one output? type Result = | Success | ValidationError | UpdateError | SmtpError Request Errors SuccessValidate Update Send Failure A single function representing the use case
  • 25. Functional design How can a function have more than one output? type Result = | Success | Failure Request Errors SuccessValidate Update Send Failure A single function representing the use case
  • 26. Functional design How can a function have more than one output? type Result<'TEntity> = | Success of 'TEntity | Failure of string Request Errors SuccessValidate Update Send Failure A single function representing the use case
  • 27. Functional design Request Errors SuccessValidate Update Send Failure A single function representing the use case • Each use case will be equivalent to a single function • The function will return a sum type with two cases: "Success" and "Failure". • The use case function will be built from a series of smaller functions, each representing one step in a data flow. • The errors from each step will be combined into a single "failure" path.
  • 28. How do I work with errors in a functional way?
  • 48. v
  • 64. Monads are confusing? Monads are not really that confusing http://bit.ly/monad-paper
  • 65. Railway oriented programming This has absolutely nothing to do with monads.
  • 66. A railway track analogy The Tunnel of Transformation Function apple -> banana
  • 67. A railway track analogy Function 1 apple -> banana Function 2 banana -> cherry
  • 68. A railway track analogy >> Function 1 apple -> banana Function 2 banana -> cherry
  • 69. A railway track analogy New Function apple -> cherry Can't tell it was built from smaller functions!
  • 70. An error generating function Request SuccessValidate Failure let validateInput input = if input.name = "" then Failure "Name must not be blank" else if input.email = "" then Failure "Email must not be blank" else Success input // happy path
  • 76. The two-track model in practice
  • 79. Composing switches Validate UpdateDb SendEmail >> >> Composing one-track functions is fine...
  • 80. Composing switches Validate UpdateDb SendEmail >> >> ... and composing two-track functions is fine...
  • 81. Composing switches Validate UpdateDb SendEmail   ... but composing switches is not allowed!
  • 82. Composing switches Validate Two-track input Two-track input Validate One-track input Two-track input  
  • 83. Building an adapter block Two-track input Slot for switch function Two-track output
  • 84. Building an adapter block Two-track input Two-track output Validate Validate
  • 85. let adapt switchFunction = fun twoTrackInput -> match twoTrackInput with | Success s -> switchFunction s | Failure f -> Failure f Building an adapter block Two-track input Two-track output
  • 86. let adapt switchFunction = fun twoTrackInput -> match twoTrackInput with | Success s -> switchFunction s | Failure f -> Failure f Building an adapter block Two-track input Two-track output
  • 87. let adapt switchFunction = fun twoTrackInput -> match twoTrackInput with | Success s -> switchFunction s | Failure f -> Failure f Building an adapter block Two-track input Two-track output
  • 88. let adapt switchFunction = fun twoTrackInput -> match twoTrackInput with | Success s -> switchFunction s | Failure f -> Failure f Building an adapter block Two-track input Two-track output
  • 89. Bind as an adapter block Two-track input Two-track output let bind switchFunction = fun twoTrackInput -> match twoTrackInput with | Success s -> switchFunction s | Failure f -> Failure f bind : ('a -> TwoTrack<'b>) -> TwoTrack<'a> -> TwoTrack<'b>
  • 90. Bind as an adapter block Two-track input Two-track output let bind switchFunction twoTrackInput = match twoTrackInput with | Success s -> switchFunction s | Failure f -> Failure f bind : ('a -> TwoTrack<'b>) -> TwoTrack<'a> -> TwoTrack<'b>
  • 91. name50 Bind example let nameNotBlank input = if input.name = "" then Failure "Name must not be blank" else Success input let name50 input = if input.name.Length > 50 then Failure "Name must not be longer than 50 chars" else Success input let emailNotBlank input = if input.email = "" then Failure "Email must not be blank" else Success input nameNotBlank emailNotBlank
  • 92. Bind example nameNotBlank (combined with) name50 (combined with) emailNotBlank nameNotBlank name50 emailNotBlank
  • 93. Bind example bind nameNotBlank bind name50 bind emailNotBlank nameNotBlank name50 emailNotBlank
  • 94. Bind example bind nameNotBlank >> bind name50 >> bind emailNotBlank nameNotBlank name50 emailNotBlank
  • 95. Bind example let validateRequest = bind nameNotBlank >> bind name50 >> bind emailNotBlank // validateRequest : TwoTrack<Request> -> TwoTrack<Request> validateRequest
  • 96. Bind example let (>>=) twoTrackInput switchFunction = bind switchFunction twoTrackInput let validateRequest twoTrackInput = twoTrackInput >>= nameNotBlank >>= name50 >>= emailNotBlank validateRequest
  • 97. Bind doesn't stop transformations FunctionB type TwoTrack<'TEntity> = | Success of 'TEntity | Failure of string FunctionA
  • 98. Composing switches - review Validate UpdateDb SendEmail Validate UpdateDb SendEmail
  • 99. Comic Interlude What do you call a train that eats toffee? I don't know, what do you call a train that eats toffee? A chew, chew train!
  • 100. More fun with railway tracks... Working with other functions
  • 101. More fun with railway tracks... Fitting other functions into this framework: • Single track functions • Dead-end functions • Functions that throw exceptions • Supervisory functions
  • 102. Converting one-track functions Fitting other functions into this framework: • Single track functions • Dead-end functions • Functions that throw exceptions • Supervisory functions
  • 103. Converting one-track functions // trim spaces and lowercase let canonicalizeEmail input = { input with email = input.email.Trim().ToLower() } canonicalizeEmail
  • 104. Converting one-track functions UpdateDb SendEmailValidate canonicalizeEmail Won't compose
  • 105. Converting one-track functions Two-track input Slot for one-track function Two-track output
  • 106. Converting one-track functions Two-track input Two-track output CanonicalizeCanonicalize
  • 107. Converting one-track functions Two-track input Two-track output let map singleTrackFunction = fun twoTrackInput -> match twoTrackInput with | Success s -> Success (singleTrackFunction s) | Failure f -> Failure f map : ('a -> 'b) -> TwoTrack<'a> -> TwoTrack<'b>` Single track function
  • 108. Converting one-track functions Two-track input Two-track output let map singleTrackFunction = bind (singleTrackFunction >> Success) map : ('a -> 'b) -> TwoTrack<'a> -> TwoTrack<'b> Single track function
  • 109. Converting one-track functions UpdateDb SendEmailValidate canonicalizeEmail Will compose
  • 110. Converting dead-end functions Fitting other functions into this framework: • Single track functions • Dead-end functions • Functions that throw exceptions • Supervisory functions
  • 111. Converting dead-end functions let updateDb request = // do something // return nothing at all updateDb
  • 113. Converting dead-end functions One-track input Slot for dead end function One-track output
  • 114. Converting dead-end functions One-track input One-track output let tee deadEndFunction oneTrackInput = deadEndFunction oneTrackInput oneTrackInput tee : ('a -> unit) -> 'a -> 'a Dead end function
  • 116. Functions that throw exceptions Fitting other functions into this framework: • Single track functions • Dead-end functions • Functions that throw exceptions • Supervisory functions
  • 117. Functions that throw exceptions One-track input Two-track output SendEmail SendEmail Add try/catch to handle timeouts, say Looks innocent, but might throw an exception
  • 118. Functions that throw exceptions EvenYoda recommends not to use exception handling for control flow: Guideline: Convert exceptions into Failures "Do or do not, there is no try".
  • 119. Supervisory functions Fitting other functions into this framework: • Single track functions • Dead-end functions • Functions that throw exceptions • Supervisory functions
  • 120. Supervisory functions Two-track input Two-track output Slot for one-track function for Success case Slot for one-track function for Failure case
  • 121. Putting it all together
  • 122. Putting it all together Validate UpdateDb SendEmail Canonicalize Input Output??
  • 123. Putting it all together Validate UpdateDb SendEmail Canonicalize returnMessage Input Output let returnMessage result = match result with | Success obj -> OK obj.ToJson() | Failure msg -> BadRequest msg
  • 124. Putting it all together - review The "two-track" framework is a useful approach for most use-cases. You can fit most functions into this model.
  • 125. Putting it all together - review The "two-track" framework is a useful approach for most use-cases. let updateCustomer = receiveRequest >> validateRequest >> updateDbFromRequest >> sendEmail >> returnMessage let updateCustomer = receiveRequest >> validateRequest >> updateDbFromRequest >> sendEmail >> returnMessage Let's look at the code -- before and after adding error handling
  • 126. Comic Interlude Why can't a steam locomotive sit down? I don't know, why can't a steam locomotive sit down? Because it has a tender behind!
  • 127. Extending the framework: • Designing for errors • Parallel tracks • Domain events
  • 128. Designing for errors Unhappy paths are requirements too
  • 129. Designing for errors let validateInput input = if input.name = "" then Failure "Name must not be blank" else if input.email = "" then Failure "Email must not be blank" else Success input // happy path type TwoTrack<'TEntity> = | Success of 'TEntity | Failure of string Using strings is not good
  • 130. Designing for errors let validateInput input = if input.name = "" then Failure NameMustNotBeBlank else if input.email = "" then Failure EmailMustNotBeBlank else Success input // happy path type TwoTrack<'TEntity> = | Success of 'TEntity | Failure of ErrorMessage type ErrorMessage = | NameMustNotBeBlank | EmailMustNotBeBlank Special type rather than string
  • 131. Designing for errors let validateInput input = if input.name = "" then Failure NameMustNotBeBlank else if input.email = "" then Failure EmailMustNotBeBlank else if (input.email doesn't match regex) then Failure EmailNotValid input.email else Success input // happy path type ErrorMessage = | NameMustNotBeBlank | EmailMustNotBeBlank | EmailNotValid of EmailAddress Add invalid email as data
  • 132. Designing for errors type ErrorMessage = | NameMustNotBeBlank | EmailMustNotBeBlank | EmailNotValid of EmailAddress // database errors | UserIdNotValid of UserId | DbUserNotFoundError of UserId | DbTimeout of ConnectionString | DbConcurrencyError | DbAuthorizationError of ConnectionString * Credentials // SMTP errors | SmtpTimeout of SmtpConnection | SmtpBadRecipient of EmailAddress Documentation of everything that can go wrong -- And it's type-safe documentation that can't go out of date!
  • 133. Designing for errors type ErrorMessage = | NameMustNotBeBlank | EmailMustNotBeBlank | EmailNotValid of EmailAddress // database errors | UserIdNotValid of UserId | DbUserNotFoundError of UserId | DbTimeout of ConnectionString | DbConcurrencyError | DbAuthorizationError of ConnectionString * Credentials // SMTP errors | SmtpTimeout of SmtpConnection | SmtpBadRecipient of EmailAddress Documentation of everything that can go wrong -- And it's type-safe documentation that can't go out of date! As we develop the code, we can build up a complete list of everything that could go wrong
  • 134. Designing for errors – converting to strings No longer works – each case must now be explicitly converted to a string returnMessage let returnMessage result = match result with | Success _ -> "Success" | Failure msg -> msg
  • 135. Designing for errors – converting to strings let returnMessage result = match result with | Success _ -> "Success" | Failure err -> match err with | NameMustNotBeBlank -> "Name must not be blank" | EmailMustNotBeBlank -> "Email must not be blank" | EmailNotValid (EmailAddress email) -> sprintf "Email %s is not valid" email // database errors | UserIdNotValid (UserId id) -> sprintf "User id %i is not a valid user id" id | DbUserNotFoundError (UserId id) -> sprintf "User id %i was not found in the database" id | DbTimeout (_,TimeoutMs ms) -> sprintf "Could not connect to database within %i ms" ms | DbConcurrencyError -> sprintf "Another user has modified the record. Please resubmit" | DbAuthorizationError _ -> sprintf "You do not have permission to access the database" // SMTP errors | SmtpTimeout (_,TimeoutMs ms) -> sprintf "Could not connect to SMTP server within %i ms" ms | SmtpBadRecipient (EmailAddress email) -> sprintf "The email %s is not a valid recipient" email Each case must be converted to a string – but this is only needed once, and only at the last step. All strings are in one place, so translations are easier. returnMessage (or use resource file)
  • 136. Designing for errors - review type ErrorMessage = | NameMustNotBeBlank | EmailMustNotBeBlank | EmailNotValid of EmailAddress // database errors | UserIdNotValid of UserId | DbUserNotFoundError of UserId | DbTimeout of ConnectionString | DbConcurrencyError | DbAuthorizationError of ConnectionString * Credentials // SMTP errors | SmtpTimeout of SmtpConnection | SmtpBadRecipient of EmailAddress Documentation of everything that can go wrong. Type-safe -- can't go out of date!
  • 138. Parallel validation nameNotBlank name50 emailNotBlank Problem: Validation done in series. So only one error at a time is returned
  • 140. Combining switches + Trick: if we create an operation that combines pairs into a new switch, we can repeat to combine as many switches as we like.
  • 141. Combining switches + + Trick: if we create an operation that combines pairs into a new switch, we can repeat to combine as many switches as we like.
  • 142. Combining switches + + Trick: if we create an operation that combines pairs into a new switch, we can repeat to combine as many switches as we like.
  • 143. Domain events Communicating information to downstream functions
  • 144. Events are not errors Validate UpdateDb SendEmail Tell CRM that email was sent
  • 145. Events are not errors Validate UpdateDb SendEmail Tell CRM that email was sent type MyUseCaseMessage = | NameMustNotBeBlank | EmailMustNotBeBlank | EmailNotValid of EmailAddress // database errors | UserIdNotValid of UserId // SMTP errors | SmtpTimeout of SmtpConnection // Domain events | UserSaved of AuditInfo | EmailSent of EmailAddress * MsgId
  • 146. Events are not errors Validate UpdateDb SendEmail Tell CRM that email was sent type MyUseCaseMessage = | NameMustNotBeBlank | EmailMustNotBeBlank | EmailNotValid of EmailAddress // database errors | UserIdNotValid of UserId // SMTP errors | SmtpTimeout of SmtpConnection // Domain events | UserSaved of AuditInfo | EmailSent of EmailAddress * MsgId type TwoTrack<'TEntity> = | Success of 'TEntity * Message list | Failure of Message list
  • 147. Comic Interlude Why can't a train driver be electrocuted? I don't know, why can't a train driver be electrocuted? Because he's not a conductor!
  • 148. Some topics not covered... ... but could be handled in an obvious way.
  • 149. Topics not covered • Errors across service boundaries • Async on success path (instead of sync) • Compensating transactions (instead of two phase commit) • Logging (tracing, app events, etc.)
  • 150. Summary A recipe for handling errors in a functional way
  • 151. Recipe for handling errors in a functional way type TwoTrack<'TEntity> = | Success of 'TEntity * Message list | Failure of Message list Validate UpdateDb SendEmail type Message = | NameMustNotBeBlank | EmailMustNotBeBlank | EmailNotValid of EmailAddress
  • 153. I don’t always have errors...
  • 154. I don’t always have errors... Railway Oriented Programming @ScottWlaschin fsharpforfunandprofit.com FPbridge.co.uk http://bit.ly/rop-example