►
From YouTube: Rust Linz, January '22 - Error Handling in Rust - A Pragmatic Approach by Luca Palmieri
Description
Luca's talk is based on this article: https://www.lpalmieri.com/posts/error-handling-rust/
Rust does not rely on exceptions - errors are values, handled via the `Result` enum. Calling a fallible function forces you to account for errors - the type system does not let you ignore them.
Developers speak highly of Rust's approach to error handling. At the same time, they often report feeling lost and confused when modeling the unhappy path of their Rust applications. They have questions and the answers are not always straightforward: how do errors fit within the broader architecture of our application? What does a good error look like? What are errors for? Should we use a library? Which one?
This talk will offer a pragmatic framework to determine how to approach error modeling/handling in a variety of different scenarios.
About Luca Palmieri
Luca Palmieri is a Principal Engineer at TrueLayer. He is a co-organizer of the Rust London User Group and the author of "Zero To Production In Rust", an introduction to backend development using the Rust programming language.
He is the author of a few crates in the Rust ecosystem (e.g. cargo-chef, wiremock, ndarray-stats, linfa, etc.) as well as a few workshops (i.e. build-your-own-jira-with-rust and ndarray-koans).
Luca on Twitter: https://twitter.com/algo_luca
Luca's book: https://www.zero2prod.com/
We are aware of the audio issues.
A
So
does
it
work?
Yes,
it
does
so
good
evening.
Everybody,
it's
a
pleasure
to
be
here,
as
the
title
suggests,
we're
going
to
be
talking
about
error
ending
in
rust
tonight
before
we
get
started
in
case.
I
have
another
pleasure
to
meet
you
a
little
bit
of
an
introduction.
My
name
is
luca
valmieri
and
I
work
as
a
principal
engineer
at
true
layer,
financial
technology
company
based
in
london.
A
A
Speaking
of
rust,
I
have
been
doing
some
open
source
in
the
rust
community.
I've
been
doing
some
workshops
to
get
people
introduced
to
rust,
in
particular,
videos
on
gravity
trust.
I've
done
some
work
in
the
web
space,
so
faster,
lucky
builds
easier.
Testing
of
http
clients
tracing
integrations
in
practice.
Web
logging
in
general
all
the
bits
and
pieces
that
I
happen
to
solve,
because
they
are
my
own
problems
when
doing
applications.
A
The
last
year
and
a
half
I
spent
most
of
my
time
on
zero
to
production,
invest
which
is
an
opinionated
introduction
to
become
development
that
uses
rust
as
the
main
language
throughout
the
book.
It's
almost
complete
10
chapters
out
of
11.
So
if
you're
curious,
go
and
check
it
out
and
the
whole
talk
today
is
basically
a
translation
of
one
of
the
chapters,
the
one
about
ad
redlink.
A
So
if
you
read
the
book
you
might
heard
you
might
hear
some
rhymes
said
that.
Why
are
we
talking
about
the
randlink?
It's
mostly
because
I
hear
more
of
an
like
that.
Rendering
invest
is
hard,
and
I
think
that
there
is
truth
into
that
sentence.
There
is
rare
challenges
in
doing
a
rambling
correctly,
but
I
think
more
often
than
not
what
that
center
actually
hides
is
that
error
angling
in
general
is
hard.
A
There
are
different
planes
which
intersect
and
you
need
to
tackle
at
the
same
time,
if
you
combine
that
we
trust
introducing
a
different
paradigm.
So,
instead
of
using
exceptions,
it
uses
values
and
you
might
not
come
from
a
functional
language,
so
you
might
not
have
seen
that
before
then.
I
can
understand
why
people
say
rendering
and
grass
is
hard,
so
the
whole
purpose
of
today
will
be
decompracting
that
statement.
So
look
at
that
randomly
in
general
and
then
understand
how
to
model
errors.
We
trust
and
understand
how
the
different
bits
and
pieces
fit
together.
A
The
talk
is
roughly
structured
into
three
sections,
so
we're
going
to
start
with
our
last
three
section:
that's
going
to
be
anatomy
and
whenever
which
is
around
error
wrangling
in
general,
we
are
going
to
look
at
the
tools
to
model
errors
in
rust
and,
at
the
end,
we're
going
to
look
into
the
more
pragmatic
stuff
so
buttons
under
contents.
Libraries
that
you
can
use
and
things
you
might
want
to
do
in
your
applications
without
further
ado,
let's
get
started
so,
let's
clarify
with
the
terminology
before
we
get
any
deeper.
A
So
when
we
talk
about
errors,
we're
generally
talking
about
an
operation
that
we're
performing.
That
does
not
produce
the
desired
outcome,
and
this
usually
happens
at
runtime
and
throughout
this
section
of
the
talk.
We're
going
to
use.
Http
calls
as
the
example
which
works
pretty
well,
considering
that
daniel
is
the
next
talk
which
I
didn't
know
at
the
beginning
when
it
from
the
slide.
So
it's
7db
at
its
finest.
We
have
a
client
and
a
server.
The
client
is
using
the
server
api
to
create
an
article.
A
Imagine
that
the
server
is
some
kind
of
blogging
platform,
an
api
as
a
service,
whatever
you
prefer,
so
it's
posting
on
the
article
endpoint,
so
it's
going
to
be
a
payload
which
is
not
represented
in
the
slide
best
case
scenario.
The
server
comes
back
to
the
client
saying
200k,
like
I've
got
your
article
I
saved
it.
I
published
whatever
all
good
now.
We
all
know
that.
That's
not
necessarily
what
always
happens,
no
matter
how
well
implemented
our
code
is
or
how
many
checks
we've
done.
A
What
can
happen
is
that
the
server
comes
back
with
an
error
and
let's
look
at
one
potential
error
that
the
server
may
come
back
with
a
four
to
nine,
too
many
requests,
which
basically
means
I
cannot
handle
this
right
now.
Now
the
client
and
the
server
are
talking
a
protocol
that
they
both
understand,
which
is
http.
A
Protocol
and
http
protocol
includes
status
codes,
which
is
a
well-defined
meaning,
so
the
client
can
be
programmed
beforehand
to
actually
recognize
a
four
to
nine
status
code,
because
the
client
understands
what
that
means,
and
so
the
client
can
be
programmed
to
react
to
that
status
code
and
perform
some
kind
of
action
or
routine
as
a
reaction,
and
all
these
happens
in
an
automated
fashion.
So
the
kind
was
programmed
beforehand
nobody's
there
telling
the
client
what
to
do
at
runtime.
A
So
the
client
can
look
at
the
four
to
nine
decide
to
wait,
perhaps
an
exponential
back
off
and
then
do
some
retries
and
if
we're
lucky,
those
three
times
are
gonna
result
in
a
success.
So
what
we
actually
get
is
an
automated
recovery,
so
the
client
got
another
condition,
managed
to
perform
some
actions
and
actually
manage
to
get
a
success.
If
you're
a
user
using
this
server
using
this
client
software,
you
don't
actually
realize
that
an
error
like
this,
you
might
notice
a
little
bit
of
value
latency.
A
You
can
see
that
there's
been
a
bunch
of
retries,
but
from
your
point
of
view,
it
was
a
200
just
a
slow
one,
which
is
good
like
that's
when
software
works,
there's
other
different,
that's
other
types
of
failure
modes
which
cannot
be
resolved
as
easily.
So,
let's
imagine
that
the
server
comes
back
with
a
different
error.
This
time,
which
is
a
400
request
and
the
server
is
telling
the
client
that
the
data
they
submitted
in
the
post
article
request
is
not
quite
up
to
scratch
like
it
doesn't
actually
meet
the
requirements
of
the
server.
A
In
particular,
the
title
cannot
be
empty
titled,
which
was
part
of
the
body
the
decline
submitted.
Now
the
client
understands
what
a
400
means.
In
the
same
way,
it
understood
what
a
four
to
nine
meant,
but
there
is
no
valuable,
automated
recovery
strategy
for
the
client.
The
client
first
of
all
cannot
understand
the
message
field.
You
can
do
some
streak
matching,
but
let's
assume
it
doesn't
because
it's
not
part
of
some
enumeration
which
is
part
of
the
contract
and,
secondly,
there's
no
way
that
kind
can
autonomously
autonomously
decide.
A
A
So
the
client
is
going
to
take
the
response,
manipulate
it
and
speed
out
another
message,
which
is
the
right
level
of
context
for
the
user,
which
in
this
case
is
going
to
be
a
title,
cannot
be
empty.
Imagine
the
user
was
probably
filling
an
html
form,
and
so
this
might
be
shown
on
the
input
fields
that
require
the
title
and
the
user
can
actually
look
at
the
error
and
react
to
the
error.
So
this
happens.
This
time
is
not
automated.
It
requires
an
actual
user
in
the
loop.
A
It's
gonna
fill
in
the
title
and
resubmit,
which
hopefully
leads
to
success.
Now,
one
last
type
of
failure
mode.
This
time
the
server
goes
kaboom,
so
the
server
returns
to
the
client
of
500
internal
server
error
and
once
again
the
client
I
mean
can
try
to
do
some
stuff.
The
client
could
retire,
but
let's
assume
that
the
retry
do
not
succeed.
So
what
we
get
in
the
end
is
once
again
user
escalation,
but
the
client
cannot
tell
much
to
the
user,
because
the
client
actually
doesn't
know.
A
A
What
actually
needs
to
happen
is
that
something
needs
to
happen
on
the
other
side,
on
the
server
side,
and
that's
because
we
need
another
type
of
human
within
the
operator
like
the
operator
is
a
person
who
understands
how
the
server
works.
Has
the
right
level
of
permissions
to
actually
go
and
troubleshoot
the
server
and
can
actually
interpret
the
errors
that
are
coming
out
of
the
server,
so
the
operator
can
go
in
it.
A
Might
have
been
paged
by
an
automated
alert
they
might
have
been
conducted
because
the
user
got
in
touch
with
support,
saying
your
software
doesn't
work
somehow
they
got
into
the
picture,
and
so
they
go
there.
They
look
at
logs
and
they
look
at
traces
and
metrics
and
whatever
type
of
diagnostic
the
server
has
and
they
spot
that
line.
That
says,
fail
to
execute
sql
query:
there
is
no
available
connection
in
the
pool.
The
operator
knows
how
the
server
works.
So
he
knows
that
the
server
is
trying
to
insert
the
article
inside
a
database.
A
Now,
in
all
these
three
scenarios,
we
examined
the
four
to
nine,
the
400,
the
500.
We
had
one
api
error
that
was
traveling
between
the
server
and
the
client
and
that
api
error
had
to
satisfy
three
different
audiences.
There
was
always
a
user,
there
was
always
an
operator
and
there
was
always
a
machine.
A
The
machine,
as
we
said,
needs
a
stable
contract
because
it
needs
to
be
programmed
to
react
to
that
stable
contract.
So
if
he
doesn't
know
the
contract
beforehand,
we
cannot
program
it
to
actually
react
when
certain
situation
arise
and
the
machine
roughly
has
two
modes
of
operation,
so
automatic
recovery
in
a
general
sense.
So
you
can
try
to
do
some
actions
as
a
result
of
an
error
which
might
lead
to
ignoring
the
error
by
trying
the
error
using
a
different
strategy
to
get
a
success
or
you
can
escalate.
A
A
So
what
that
means
is
that
they
cannot
go
in
and
actually
troubleshoot.
If
the
server
is
not
working,
they
need
another
another
message
which
is
tuned
to
their
level
of
context,
which
means
it's
tuned
to
somebody
who's
using
the
software
but
doesn't
understand
the
actual
implementation
of
the
software.
A
Last
but
not
least,
we
have
operators
operators
understand
the
inner
working
of
the
system,
so
they
understand
how
the
all
different
things
fit
together,
but
I
mean
what
they
can
get
to
understand
it
given
enough
time.
So
what
they
need
is
as
much
context
as
possible.
They
need
to
get
each
piece
of
diagnostic
data.
They
can
possibly
get
because
every
single
one
of
those
is
a
breadcrumb
they
might
want
to
follow
when
they're
trying
to
debug.
A
A
So
in
the
next
section,
what
we're
going
to
look
at
is
that
we
can
use
the
tools
that
gives
us
as
a
language
to
actually
mod
letters.
I
see
some
people
are
complaining
about
the
mic,
so
I'm
going
to
try
to
tune
the
game
very
quickly.
Hopefully
that
is
better
cool
so
for
the
next
section,
which
is
gonna,
be
let's
say,
roughly
10
minutes,
but
I'll
ask
you
to
forget
about
our
steroid
landline
works,
so
forget
about
the
error
trade
forget
about
standard
library
in
general.
A
What
we're
going
to
try
to
do
is
model
errors
in
brass,
using
the
tools
given
us
from
the
language
so,
first
and
foremost,
to
know
to
solve
a
problem.
You
need
to
know
that
a
problem
exists
so
step
number
one
we
need
to
detect
if
an
error
has
happened,
that's
going
to
be
the
first
thing
we're
going
to
do
to
do
that,
we're
going
to
use
an
enumeration
so
we're
going
to
keep
using
the
create
article
example.
Throughout
the
talk
so
create
article
is
going
to
be
a
function.
A
A
So,
okay,
when
we
actually
call
create
article,
given
that
we
use
it,
we've
been
using
an
enum.
That
means
that
we
cannot
go
on
and
assume
that
everything
worked,
so
we're
actually
forced
to
use
a
match
statement
to
decide
which
of
the
two
variants
we're
actually
looking
at.
If
we're
looking
at
uk
variant,
we
can
extract
the
article
identifier
and
that
can
be
used,
then,
in
whatever
processing
we
want
to
do.
If
we're
looking
at
the
other
variant,
then
we
know
that
something
has
gone
wrong.
A
A
A
This
unfortunately
works
but
doesn't
work
because,
as
we
said
before,
is
that
one
we
have
two
audiences
like
web
users
and
web
operators.
If
we're
not
optimizing
for
users,
then
the
operators
are
not
getting
enough
details.
If
we're
only
optimizing
for
operators,
then
the
users
are
getting
a
lot
of
videos
that
they
don't
understand,
which
is
definitely
a
bad
experience,
so
it
is
like
it's
better
than
before,
but
makes
everybody
pissed,
depending
on
who
you
optimize
for
so
third
step.
A
We
want
to
provide
different
error
messages
to
users
and
operators
and
we're
going
to
do
that
in
the
most
obvious
way
possible.
So
we're
going
to
add
another
field,
so
we're
going
to
have
a
user
report
field,
which
is
a
string
and
we're
going
to
have
an
operator
report
field
which
is
also
string,
and
so
when
something
goes
wrong.
A
A
Unfortunately,
one
this
is
okay
for
error,
reporting
doesn't
quite
work
for
control
flow.
We
want
to
do
different
actions
like
reties
as
we
discussed
before.
We
need
to
do,
go
and
do
string
matching.
Let
me
to
go
and
say:
does
the
error
report
contain
this
sentence,
which
is
not
great,
because
the
credit
report
might
change?
It's
not
part
of
the
api
contract.
A
What
we
want
is
we
want
a
stable
contract
which
enables
us
to
do
proper
control
flow,
robust,
that's
going
to
be
there,
even
if
things
change
and
we're
going
to
notice
and
the
way
you
do
that
is
you
add
another
generic
parameter,
so
we're
going
to
have
an
error
type
parameter.
It's
going
to
be
an
additional
field
inside
the
other
bucket.
That
error
can
be
any
type,
but
we're
going
to
use
an
enumeration
because
we
have
a
finite
number
of
errors.
A
So,
once
again,
finite
number
of
states
enums
are
what
kills
the
game
so
we're
gonna
use
a
create
article
error.
That's
three
buttons,
and
this
allows
us
instead
of
doing
string
matching,
as
we
were
doing
just
a
few
moments
ago,
to
actually
go
and
match
the
specific
variant.
This
is
a
variety
of
advantages.
If
that
pattern
disappears,
the
code
is
gonna
break,
so
we're
gonna
know
that
that
is
no
longer
a
failure
mode
possible.
A
So
we
can
remove
a
bunch
of
that
code
if
new
variants
are
introduced
and
we're
actually
using
a
match
statement.
We're
gonna
get
a
compilation
error,
because
our
match
is
no
longer
exhaustive,
so
we're
gonna
have
to
go
and
think.
How
should
I
handle
the
new
error
that
has
just
popped
up.
So
all
in
all,
this
is
good
enough
for
us
to
do
counterflow
so
to
decide.
A
If
this
happens,
I'm
gonna
do
this,
but,
as
you
might
imagine,
there's
a
little
bit
of
duplication
here,
because
we
have
a
user
report,
an
operator
report
and
an
error
type
and
the
error
type
probably
contains
overlapping
information
with
what's
contained
inside
the
user
report
and
the
operator
report.
Furthermore,
the
user
report
in
the
operator
report
are
generated
in
any
case,
even
if
they're
not
used,
so
even
if
we
retry,
for
example,
and
that
actually
leads
to
us
succeeding,
we
still
generally
use
a
report
that
was
never
used.
A
So
there's
a
bunch
of
string
allocations
and
general
inefficiency
that
we
don't
like.
So
what
we
can
do
is
we
can
try
to
make
that
lazy.
Now
we
could
do
this
by
adding
two
methods.
A
user
report
method
and
an
operator
report
method
the
return
string
by
the
standard
library.
Now
I'm
gonna
bring
it
back
into
the
picture
as
two
methods
that
we
already
know,
there's
two
traits
that
we
already
know
one
is
called
the
bug
and
the
other
one
is
called
display.
A
So
the
bug
is
usually
used
and
suggested
for
use
when
you
want
to
get
some
developer
representation
of
a
type
down
into
the
nitty-gritty
display
instead
is
suggested
when
you
want
some
nicely
formatted
representation
of
a
type,
and
so
we
can
hijack
these
two
traits
and
say
we're
going
to
use
the
bug
for
the
report
and
we're
going
to
use
display
for
the
user
report,
and
so
it's
just
enough
for
the
error
type
to
implement
these
two
things.
And
so
then,
if
we
need
we
can
generate
the
reports
we
need,
and
these
are
in
demand.
A
So
there's
no
waste
they're
only
generating
when
they
need
it.
Six
step
code
in
general
is
more
complicated
than
just
an
entry
point
that
calls
a
function
and
then
kind
of
fails
or
succeeds.
It's
usually
a
function
that
calls
a
function
that
calls
three
other
functions
that
in
turn
called
three
other
five
functions.
A
So
it's
a
layered
cake,
it's
more
like
a
birthday
cake,
and
so
what
happens
in
our
case,
for
example,
that
create
article
is
not
going
to
implement
http
protocol
from
scratch.
It's
going
to
invoke
some
other
function,
probably
from
a
library
that
is
going
to
send
an
http
request
and
that
can
fail
and
speaks
a
different
level
of
structure.
So
speaks
about
http
responses
and
http
errors.
A
Now
our
critical
error
has
three
variants
right.
So
what
is
actually
happening
in
genetic
error?
We
can
imagine,
or
we
can
infer
that
genetic
error
is
actually
the
mapping
of
something
that
has
happened.
That
has
gone
wrong
in
the
hdp
layer,
but
genetic
error
itself
doesn't
contain
any
information
about
the
source.
What
this
means
is
that
we
actually
go
and
generate
the
user
report
or
the
error
or
the
operator
report.
This
is
going
to
be
very
poor
because
it
actually
doesn't
include
the
details
that
would
be
key
to
troubleshoot,
especially
for
the
operator.
A
Now
that
source
is
useful,
but
is
also
problem.
Api
wise,
because
that
http
error
is
a
concrete
type,
so
it
might
be.
For
example,
I
don't
know
the
error
type
returned
by
request
or
a
time
by
serve
or
returned
by
urec
or
whatever
other
http
client.
You
might
be
using
request
and
you
don't
want
to
change
or
break
your
api
when
you
change
the
implementation
or
create
article,
so
you
want
to
be
able
to
swap,
for
example,
http
client
implementation.
A
We
now
then
need
to
bump
up
your
library,
major
version.
So
one
thing
we
can
use
is
a
common
technique
in
rust
called
type
erasure.
So
we
want
to
make.
We
want
still
want
to
store
the
source,
but
we
don't
want
to
expose
the
type
and
one
way
to
do
that
is
to
use
straight
objects,
which
is
basically
to
say
I
have
a
pointer
to
a
type.
I
don't
know
what
type
it
is.
A
So
the
usual
pattern
is
that
you
define
a
new
trait
which
requires
the
lf2
trait
as
prerequisites,
and
then
you
use
that
in
your
trade
object.
So
that's
why
we're
going
to
introduce
an
error
trait,
which
requires
its
implementers
to
implement
the
bug
in
display
and
then
we're
going
to
say
that
the
source
is
a
trait
object
for
the
error
trait,
and
this
works.
A
So
we
need
to
be
able
to
get
the
source
of
the
source,
and
at
this
point
in
time
that
doesn't
quite
work,
because
the
only
thing
we
know
about
the
source,
by
definition
of
it
being
a
trade
object,
is
that
it
implements
the
error
rate,
which
means
it
can
be
displayed
as
an
operator
report
and
as
a
user
report,
nothing
else
there's
no
way
for
us
to
get
the
source.
So
what
we
need
to
do
is
we
need
to
change
the
error
trade.
A
We
need
to
add
a
source
method
in
there
which
we
can
use
to
get
the
source
of
that
letter.
This
returns
an
option
because
this
might
be
the
leaf
feather.
So
the
very
first
error
that
was
generated,
in
which
case
there
is
no
source-
or
this
could
be
an
intermediate
letter,
in
which
case
there
is
a
source
for
the
same
reason
that
we
don't
want
to
show
the
concrete
type
here
as
well
we're
using
a
dyna
we're
using
a
thread
object,
so
we're
adding
the
actual
type
of
the
source.
A
A
So,
let's
start
from
the
error
trade,
so
arrow
trade
is
the
one
on
the
left.
The
sum
of
the
libraries
is
the
one
on
the
right,
as
you
can
see,
is
actually
quite
close,
and
I'm
not
gonna
like
pretend
that
I
didn't
know
where
we
were
going
so
that
obviously
it
looks
quite
close,
but
it's
good
to
go
and
look
at
the
specific
differences.
A
So
the
standard
library
makes
the
same
usage
of
the
bug
and
display
summer
library
has
a
source
method
as
well,
the
difference
being
that
the
source
method
makes
an
additional
request
on
the
trade
object
that
it's
returning.
So
it
requires
it
to
be
valid
for
a
static
lifetime,
and
this
is
a
technical
reason
which
is
useful
to
be
able
to
downcast.
So
together,
concrete
type
back
from
the
trade
object.
As
you
can
see,
originally
the
standard
library
had
a
different
method,
naming
codes
which
had
exactly
the
same
signature
of
our
source
method.
A
So
they've
got
time
to
learn
and
to
iterate.
We
just
did
something
in
20
minutes,
so
that's
pretty
fair.
You
can
see
also
that
the
standard
library
has
a
duplicated
description
method
which
originally
filled
the
same
purpose
of
the
display
implementation.
So
it
was
meant
for
a
user
user
phasing
report
or
a
nicely
formatted
representation
when
we
look
at
the
foldable,
so
at
our
actual
concrete
enum,
the
one
that
replaces
result
from
the
standard
library
is
extremely
similar.
A
The
main
difference
is
that
our
type
requires
the
error,
the
error
generic
parameter
to
implement
the
error.
The
standard
library
doesn't
there's
two
reasons
for
that.
The
first
one
is
the
standard
library
tries
to
be
more
conservative,
so
it
tries
to
apply
the
trade
bounds
where
they're
needed.
So
you
might
find,
for
example,
that
calling
expect
on
a
result
requires
the
error
correction
to
my
debug,
because
otherwise,
there's
no
way
to
represent
them.
A
The
second
reason
is
that
there
are
specific
types
that
are
actually
very
useful
as
error
type
which
do
not
implement
the
error
trait.
This
is
a
lot
to
do
with
coherence.
Rules
like,
for
example,
box.
Dna
error
does
not
implement
the
air
trade
specialization
might
unblock
that.
If
my
understanding
is
corrected
is
correct,
but,
generally
speaking,
there's
a
rationale
for
that.
So
do
not
be
surprised
by
the
fact
that
result
does
not
require
the
error
trade
to
be
implemented
for
the
error
generic
parameter.
A
Now
that
was
quite
a
long
diversion,
so
we
kind
of
built
our
way
into
our
wrangling
from
scratch.
So
general
understanding
over
rambling
general
understanding
of
the
last
language
can
marry
the
two
together,
we're
not
going
to
have
a
look
and
what
that
means
in
practice.
So
when
you
actually
go
and
try
to
do
a
rambling
in
your
own
applications,.
A
So
so
what
are
required?
Spinning
a
lot,
so
we
covered
this
point
before,
but
let's
like
drive
it
home
again,
you
should
be
using
an
enumeration
as
your
error
type.
Every
time
you
expect
the
caller
to
react
differently
to
the
possible
failure
modes,
because
that
enables
them
to
use
a
match
statement
which
is
an
extremely
natural
way
and
very
idiomatic
way
of
actually
expressing
a
state
machine.
A
This
model
might
not
be.
A
concern
depends
on
how
sensitive
you
are
to
making
changes.
Generally
speaking,
I
think
it's
good
for
the
complete
compiler
to
break
when
a
new
variant
is
introduced,
because
that
signals
to
you
as
a
user,
that
you
actually
need
to
go
and
review
your
referendum
logic.
An
alternative
option
is
to
mark
the
enum
as
non-exhaustive,
which
means
that
the
caller
is
forced
to
add
a
catch-all
arm
in
the
match
statement,
but
that
has
some
downsides
from
the
point
of
view
of
the
user
so
evaluate
based
on
your
constraints.
A
If
you
are
implementing
an
error
which
wraps
an
underlying
error,
always
return
a
source.
If
you
can
so
always
go
there
and
properly
implement
the
error
trade,
including
the
source
method.
I'm
stressing
this
because
the
error
trade
implements
source
by
default
by
retiring,
none,
which
is
good
because,
if
you're
doing
a
leaf
error,
it's
just
a
convenience.
But
that
also
means
that,
if
you're
implementing
error
trades
manually,
you
might
forget
that
that's
required
in
order
to
return
something
as
a
source.
A
It
needs
to
implement
the
error
trade
so
follow
up
to
that,
make
sure
to
always
implement
the
error
trade
for
your
records,
which
basically
means
deriving
the
bug.
As
you
see
in
the
code
snippet,
and
implementing
the
display
trade,
which
is
just
the
user
report
for
your
error.
And
then
you
should
be
good
to
go
and
report
that
as
a
source.
A
A
A
Then,
let's
call
some
anti-buttons
out
first
codes.
Now
you
I've
defined
an
enum
for
your
errors,
so
it's
an
error
type
and
then
all
every
time
the
caller
is
invoking
your
methods
and
they're
actually
doing
error
rambling.
They
group
a
bunch
of
variants
together,
so
in
this
example,
status,
500,
502,
503
and
504
they're
always
bundled
together,
and
they
always
invoke
the
same
code
in
terms
of
our
brand
link.
That
probably
means
that
the
your
adrenaline
is
overly
detailed,
like
callers,
don't
actually
need
that
level
of
discrimination
and
you
would
be
better.
A
You
will
be
providing
a
better
api
if
it
was
a
little
bit
less
granular.
They
usually
might
give
you
a
sense
that
perhaps
is
at
the
brown
level
obstruction,
so
you
have
different
planes
or
obstruction
played
together,
so
try
to
examine
the
code
that
is
using
your
code
and
understand.
If
that's
the
case,
this
is
of
course
easier
said
than
done.
So
if
you're
running
an
application-
and
you
have
an
internal
library
that
you're
using
then
you
can
be
very,
very,
very
tailored
to
the
needs
of
the
application.
A
But,
generally
speaking,
you
need
to
be
making
assumptions
about
your
coders,
even
the
standard
library,
which
is
by
definition,
meant
for
general
purpose
usage
when
it
tries
to
create
a
vector,
for
example,
if
there
is
not
enough
memory,
if
the
allocation
fails,
it's
gonna
bike,
and
that
is
a
very
good
default
for
99.9
percent
of
the
applications.
It's
not
a
great
default.
A
If
you
have
the
linux
kernel,
in
which
case
you
should
use
a
different
api,
but
there's
not
necessarily
a
good
reason
to
inflict
an
api
which
is
well
suited
to
the
linux
kernel
to
people
of
writing.
Something
completely
different
so
going
to
the
lower
possible
denominator
is
not
necessarily
better
so
try
to
understand
what
you're
trying
to
do
now.
The
codes
now
and,
let's
see
this
a
lot
in
libraries-
is
to
have
a
single
enum
error
type
and
use
that
across
multiple
functions
which
are
similar,
but
not
quite
the
same.
A
So
in
this
case
I'm
using
a
github
client
as
an
example,
you
have
a
create
client
function
that
creates
an
instance
of
the
github
client,
and
this
may
fail
in
some
ways,
but
probably
it's
not
doing
an
io.
It's
just
reading
some
configuration,
and
so
what
you
see
is
that
your
caller's
code
only
handles
certain
variants
and
then
just
that's
unreachable
for
the
other
bodies.
That
is
a
sign
that
put
ups.
You
need
different
error
types
that
are
a
little
bit
more
granular.
A
As
we
said
during
the
error
and
link
marathon,
we
did
before
always
erase
the
type
of
your
source
error
unless
you
have
a
very
good
reason
not
to
it's
going
to
make
your
api
more
stable
and
it
also
communicates
an
intent
to
the
coder.
It
tells
the
caller
you
shouldn't
care
about
what's
inside
here,
apart
from
the
fact
that
you
can
print
it,
and
that
should
be
pretty
much
it
at
the
tip.
If
you
need
an
opaque
error
type,
you
can
use
box
dinette,
that's
one
way
of
doing
it.
You
can
also
use
dna
outgrade.
A
The
output
provides
you
with
an
error
type.
The
letter
type
is
a
little
bit
smaller,
so
it's
one
board
instead
of
two
and
also
has
a
bunch
of
convenience
methods,
we're
going
to
see
in
a
second
12
contacts
at
the
different
layers
of
the
stack
by
default.
It
also
has
a
debug
representation,
which
provides
the
entire
error
chain,
which
is
quite
good
if
you're
logging
errors
out
to
operators.
A
A
This
error
is
a
convenience
when
you
need
to
write
an
error
in
them
and
you
don't
want
to
go
in
and
spell
out
all
the
different
bits
and
pieces,
but
you
might
need
arrheniums
in
applications
and
you
might
need
the
packages
in
libraries
so
do
not
mix
these
things
up
because
actually
leads
to
code.
That
does
not
work
as
it
should.
A
If
you're
using
any
owl,
you
can
take
advantage
of
its
context
methods,
so
you
can
try
when
you
have
a
workflow
which
spawns
multiple
abstraction
layers,
so
imagine
you're
doing
a
pr
launch
for
a
product,
and
so
your
pr
launch,
workflow
and
part
of
the
workflow
is
publishing
a
launch
article,
which
then
invokes
the
create
article
function,
which
then
does
initially
vehicle.
Each
of
these
things
is
a
very
different
level
of
instruction.
A
One
thing
that
is
nice
is
being
able
to
read
an
algorithm
report
that
says
I
failed
to
do.
The
loan
failed
to
publish
the
pr
launch
article,
which
was
caused
by
me,
failing
to
do
failing
to
create
an
article
which
was
closed
by
a
time
from
the
server,
so
you
can
see
the
intent
at
the
top
and
then
you
go
into
implementation
details
that
makes
it
very
easy
for
an
operator
to
understand.
A
What's
going
on
so,
if
you're
using
anyhow
take
advantage
of
this,
and
as
we
stress
throughout
the
call,
every
time
we
were
talking
about
source,
you
really
need
to
capture
the
whole
letter
chain
in
your
logs.
Otherwise,
it's
very
difficult
for
operators
to
go
and
troubleshoot
something
that
says
I
fail
to
get
an
article
or
fail
to
open
a
connection
like
what
were
you
doing?
What's
the
context
around
that?
Why
am
I
doing
that?
A
A
So
I
hope
I
hope
it
was
interesting
for
the
past
30
minutes.
I
realized
I
focus
mostly
on
recoverable
errors,
because
I
think
that's
where
most
of
the
doubts
are
when
it
comes
to
running
in
rust.
Panics
are
a
lot
easier
to
an
extent
it's
when
something
is
unrecoverable
and
you
just
want
to
print
something
out
to
the
user.