►
From YouTube: Errors and error handling - Jozi.js September
Description
Join us online 🌍 as we dive into dealing with errors on the web. We will talk about what some of the problems are with error handling in JavaScript and how best to deal with them. When we should throw errors, and how we should catch them, as well as what we should do about them. Bring your insights, comments and questions.
Agenda:
• 18:30 - Introduction - Sheena O'Connell
• 18:40 - Catching errors - Lucky Nkosi
• 18:50 - Throwing errors - Ruddy Riba
• 19:00 - Logging errors - Mike Geyser
• 19:10 - Debugging and recovering from errors - Gergana Young
• 19:20 - Q & A
• 19:30 - End
💛Code of conduct: https://docs.google.com/document/d/1j-OfcTwYejEj-WiQq9F9AcVv2L-Ki81RuhFTjquDJyk/edit?usp=sharing
A
Be
good:
okay,
welcome
to
jersey,
js
everybody!
It
is
great
to
see
all
your
smiling
faces.
We
have
a
code
of
conduct
and,
as
you
can
see,
it's
really
in-depth
and
complicated
because
it
needs
to
be
basically
we
want
you
guys
to
treat
each
other
well
because
we're
a
community
and
because
we're
all
here
to
learn
something
so
just
like
just
just
be
good.
A
We
if
at
any
point
in
time
you
feel
uncomfortable
and
or
somebody
seems
to
be
breaking
our
code
of
conduct,
please
reach
out
to
one
of
our
council
of
wizards,
so
I
think
we're
actually
all
in
this
call,
which
is
fantastic.
We
are
real
habit,
real
wizards,
because
we
have
real
hats.
I'd
like
to
thank
our
sponsors,
so
innocence
sponsors,
the
stream
and
microsoft
sponsors
our
meetup.
So
thank
you
to
you
guys
who
make
this
stuff
very
possible
yeah.
A
A
Not
all
errors
are
hilarious,
so,
like
the
reason
that
this
talk
topic
came
up
is
because
of
situations
like
this,
so
there
are
a
lot
of
very
terrible
javascript
tutorials
out
there
in
the
wild,
and
you
see
this
kind
of
code,
all
over
the
place
recommended
to
people
who
are
like
a
lot
of
them
are
just
learning
how
to
code,
and
this
is
what
they
see
and
they
see
it
without
any
context.
This
is
like
when
like.
Why
would
you
do
this?
A
Why
wouldn't
you
do
this,
and
so
you'll
see
this
sort
of
code
all
over
the
place,
and
it's
generally
a
bad
idea.
Areas
exist
for
a
reason
they
exist
in.
They
exist
in
multiple
languages
right,
so
it's
not
just
javascript
python
enclosure
and
java
and
c-sharp,
and
you
know
like
it's
all
over
the
place,
because
these
things
are
actually
useful.
It's
not
that
they
exist,
so
they
can
be
squashed
and
written
down
in
a
log
somewhere,
and
these
are
tools
we
can
make
use
of.
A
So
when
you're
dealing
with
errors,
you
just
need
to
be
quite
thoughtful
in
what
you're
doing,
and
so
that's
why
we're
talking
about
this?
We're
going
to
teach
you
a
bunch
of
stuff
about
good
practices
and
how
to
hopefully
do
these
things
right
and
yeah.
We
hope
it's
very
useful.
C
B
B
Cool,
I
want
you
slides
I'll,
just
talk
about
it.
We
are
a
community.
After
all,
so
yeah,
I
think
the
topic
of
when
to
actually
catch
errors
is,
is
probably
one
of
the
most
contentious
ones.
I've
worked
in
teams
that
do
things
very
differently
and
the
example
that
you
had
sheena
where
you
basically
catch
absolutely
everything.
I've
actually
seen
those
in
a
lot
of
production
systems
that
I've
worked
on
as
well.
B
So
it's
actually
quite
interesting,
my
my
my
approach
to
to
catching
errors.
I
think
they
are
generally
about
two
things
that
I
look
at
so
the
first
is
to
understand
that
errors
can
happen
anyway,
but
you
don't
necessarily
have
to
respond
everywhere
to
those
errors,
because
when
you
respond
to
an
error,
ie
catch
that
error,
you
need
to
catch
it.
Knowing
what
you're
going
to
do
with
that
error,
because
these
exceptions
that
we
throw
because
of
these
errors
actually
come
with
some
meaning
right.
B
I
think
the
first
part
that
that
sort
of
a
good
general
rule
is
to
catch
these
errors
at
your
integration
points,
and
these
integration
points
are
often
where
you
talk
to
third
parties,
whether
you
are
consuming
a
service
or
you
are
doing
some
sort
of
thing
like
going
between
your
different
architectural
layers
or
you're,
connecting
to
a
database
or
maybe
reading
from
the
file
system,
and
I
think
this
is
because
it
at
these
points,
where
you're,
integrating
with
other
pieces
of
code
or
software,
that
you
don't
have
full
control
over.
B
You
don't
know
what
could
go
wrong
and
anything
could
go
wrong,
but
when
it
does
actually
happen,
you
can
sort
of
contextualize
what
it
is
that
has
happened.
So
if
I'm
trying
to
get
data
and
data
doesn't
come
back,
I
can
understand
that
error
to
say
that
there
was
no
data
that
came
back
from
this
api
or
from
this
third
party
library,
and
I
can
do
something
with
that
piece
of
information.
B
So
that's
something
that's
going
wrong,
might
not
necessarily
be
our
fault
and
by
our
thoughts,
have
been
our
software's
fault.
But
it's
something
that
we
can
understand
and
we
can
do
something
about
it,
whether
it's
retrying
a
connection
or
whether
a
connection
is
timed
out,
and
we
now
know
that
we
have
to
retry
it
in
a
couple
of
seconds,
and
maybe
we
are
missing
some
sort
of
piece
of
information
that
we
maybe
have
or
can
can
change.
B
It's
often
at
those
integration
points
where
you
can
make
a
decision
based
off
their
exception
that
is
thrown
for
you,
and
the
critical
thing
here
is
that
you
should
probably
handle
specific
exceptions,
because
if,
if
you're
handling
a
specific
exception,
it
means
that
you
understand
what
has
gone
wrong
and
it
means
that
your
agency
to
respond
to
it
is
there
and
you
can
respond
appropriately
to
it,
so
just
console
logging.
Any
error
that
has
happened
doesn't
really
do
much.
B
It
doesn't
actually
help
you
with
with
with
what's
responding
and
making
sure
that
your
that
your
software
is
reliable
and
resilient,
and
I
think
the
second
part,
which
is
probably
just
as
important
I'd,
say
it's
at
the
last
layer
just
before
you
get
to
your
user,
because,
while
the
the
the
first
one
talks
about
how
we
integrate
with
other
pieces
of
software
that
you
don't
have
for
control
over,
this
is
at
the
point
where
you
understand
the
context
that
your
user
is,
and
here
I
use
the
term
context
while
talking
about
exceptions.
B
I
have
no
idea
what
the
user
that
initiated
this
entire
thing
was
doing
right,
which
means
that
I
can
talk
about
a
connection
error,
but
that's
meaningless
to
the
user,
whereas,
if
I'm
catching
it
just
before
the
user
chances
are,
I
understand
what
action
the
user
was
actually
trying
to
do,
which
means
that,
in
the
way
that
I
deal
with
this
part
of
the
one
of
the
things
that
I
need
to
do
is
explain
to
the
user.
B
What
has
happened
if
I'm
trying
to
log
in
if
I'm
trying
to
submit
a
phone
and
this
software
that
I'm
interacting
with,
has
experienced
some
sort
of
failure
along
the
way?
It's
at
that
point,
just
before
this
exception
bubbles
up
to
me
that
we
can
catch
these
errors
and
be
able
to
explain
to
the
user.
What
has
happened?
I
think
the
second
part
to
that
is
that
we
can
also
give
the
user
the
agency
to
respond
to
that,
because
we
understand
the
context
of
the
user.
B
So
if
the
problem
is
that
there
was
some
sort
of
or
or
the
the
solution
is
that
the
user
should
wait,
maybe
the
user
needs
to
use
a
different
means
of
getting
in
touch
with
us.
It's
at
this
point
that
we
can
understand
that
context
and
understand
how
we
can
respond
to
it
and
actually
advise
and
guide
the
user
as
to
how
to
actually
go
about
doing
that.
So
I
think
here
one
of
the
important
common
threads
between
these
two
things
that
I've
just
spoken
about
is
the
idea
of
catching
errors.
B
When
you
can
actually
do
something,
I
think
it's
very
pointless
when
we
we
just
catch
everything,
all
types
of
exceptions
at
every
every
single
level,
wrapping
everything
in
a
in
a
in
a
truck
edge
block.
I
think
that's
very
dangerous,
because
we
end
up
consuming
and
swallowing
a
lot
of
errors
that
might
actually
need
to
be
addressed
at
different
levels
of
our
system.
So
if
every
single
kind
of
code
or
function
that
we
call
has
a
a
a
try,
catch
console.log
we'll
never
actually
get
there,
because
no
one
actually
looks
at
the
console
logs
right.
B
No
one
actually
goes
into
the
production
system
and
looks
at
the
logs,
and
I
work
on
a
system,
and
I
just
realized
now
that
I,
I
don't
think
I've
looked
at
any
of
those
logs
in
the
past
year.
B
So
it's
quite
interesting
right,
because
we
we
we're
going
to
put
in
all
of
this
infrastructure
and
when
you,
unless
something
drives
you
to
go
and
take
a
look
at
those
vlogs
to
investigate.
What's
going
on
wrong,
those
actually
seldom
get
the
attention
that
they
deserve.
So
for
me,
the
best
practice
is
to
catch
these
errors.
B
Where
I
can
do
something
about
them,
either
write
the
software
in
a
way
that
makes
the
application
resilient,
so
that
application
itself
can't
respond
to
it
or
put
it
next
to
the
user
in
a
meaningful
way,
so
that
the
user
has
the
agency
to
still
be
able
to
do
what
they
actually
intended
to
do.
Yeah.
I
think
I'll
leave
it
to
that
and
we
can
discuss
it
further.
A
Awesome
would
it
be
cool
if
I
show
a
little
code
example.
I
have
some
code
that
a
student
wrote
that
I
think
demonstrates
a
lot
of
what
lucky's
saying.
So
I
I
keep
a
little
collection
of
unclean
code.
Let
me
just
share
my
share.
It.
That's.
D
A
Yeah,
because
I
have
to
tell
this
stuff
to
serving
people
so
yeah,
let
me
make
it
a
bit
bigger.
A
So
this
this
piece
of
code
was
from
the
students
who
needed
to
write
a
like
just
write
some
functionality
for
managing
some
visitors
who
came
to
visit
us
and
they
need
to
be
saved
in
the
database.
So
they
made
a
query
which
is
cool
and
then
they
try
to
like
do
the
thing
and
then
they
catch
it
and
they
just
log
the
error
and
then
they're
like
sweet,
let's
just
close
the
client.
So
this
this
is
a
problem
because
I
mean
you're,
not
gonna.
A
There's
like
a
couple
of
problems,
but
like
this.
This
catch
is
an
issue
because
imagine
how
this
function
is
going
to
be
called
like,
maybe
pulled
from
a
front
end.
Maybe
it'll
be
called
by
some
other
piece
of
client
code
right
and
how?
Let's
say
you
built
a
front
end
and
in
your
front
end
you
have
a
form
and
in
that
form
you
get
to
create
a
visitor
and
you
click
the
button
to
save
and
an
error
happens.
A
Then
what
you
know
like
where,
like,
if
something
bad
happens,
you
want
to
be
able
to
maybe
give
some
feedback
to
the
user,
and
how
is
the
client
code
going
to
know
that
there
was
an
error
like?
Are
you?
Is
the
client
code
now
going
to
be
monitoring
the
console
log?
No,
no
like?
Ideally,
you
should
just
allow
the
error
to
bubble
up
to
where
you
can
handle
it
as
lucky
said.
So
I
think
that's
an
illustration
of
at
least
part
of
what
you're
saying
yeah
yeah.
B
Absolutely
so,
actually,
sometime
last
year,
I
had
to
deal
with
the
government
department
and
I
had
to
submit
this
form
with
my
details,
a
very
niche
government
department
and
they
needed
my
details
and
and
the
kind
of
work
that
I
do
and
this
this
the
system
kept
telling
me
or
kept
kept
just
being
black.
So
it'll
come
back
and
say:
okay,
so
I
I
would
click
the
button.
It
would
look
like
things
happened
and
then
there's
there's
nothing.
B
That's
prompting
me
to
tell
me
whether
things
failed
or
succeeded
and
then
I'd
get
an
email
asking
me.
Please
capture
your
details.
Okay,
so
I
ended
up,
of
course,
pressing
f12
and
looking
at
this
at
the
dev
tools,
and
it
kept
coming
back
with
the
200
right
to
to
saying
that
everything
is
okay,
but
then
they
would
keep
telling
me
that
something's
wrong.
It
took
me
getting
a
call
with
their
I.t
department
for
them
to
say,
you're
actually
missing
that
that
that
feels
there.
B
It
was
actually
just
some
form,
validation
and
I'm
assuming
that
the
error
was
thrown
somewhere,
but
they
probably
caught
it
and
they
just
locked
it.
And
there
was
no
way
for
me
to
know
that.
I
did
something
wrong
because
clearly
I
was
the
one
who
was
capturing
incorrect
information
and
that's
where
we
started
seeing
the
problems
by
not
communicating
what
went
wrong
to
either.
C
B
C
C
Sorry,
just
the
the
thing
that
I
wanted
to
point
out.
Is
that,
like
the
only
fault
I
can
see
with
that
code
sample
is
that
they're
trying
to
catch
an
error
in
the
first
place
right
because
there's.
D
F
C
C
If
you
take
a
look
at
it
that
they're
using
the
finally
more
meaningfully
than
they're
using
the
catch
block,
but
then
I
would
suggest
that
that's
a
code
smell
right,
because
you
want
to
clean
up
your
resources
on
a
on
a
generic
manner
as
a
part
of
your
web
request
ending
if
anything
is
unused
and
considering
that
we're
talking
about
javascript
code,
you
can
just
keep
using
that
same
client
right,
getting
the
same,
reliable
reference
and
not
ever
ending.
It
actually
gives
you.
Some
performance
wins
to
be
quite
honest.
C
A
A
There
there's
another
example
I
just
made
just
now
how's
this
tell
you
right
now,
so
so
this
happens
a
lot
as
well,
when
people
make
these
gigantic
try
blocks
like
huge
and
then
like,
even
if
the
catch
is
completely
sensible.
If
something
goes
wrong
and
they
need
to
like
figure
out
what
happened
it's
like.
Is
it
the
slime?
Is
it
the
slime?
Is
it
the
slime?
Is
it
the
slime?
Just
so
like.
D
A
A
It
also
makes
the
intention
of
your
code
a
lot
clearer
if
you're
trying
catch
a
smaller
because
you'll
be
like
I'm
intending
to
catch
the
error.
That
might
happen
in
this
line
and
if
the
intention
of
your
code
is
clear,
then
again,
life
just
becomes
easier
for
you,
your
future
self.
Anybody
else
who
works
with
your
code,
like
yeah,
clear
intentions,
yeah.
C
So
I
agree
with
you
like
for
me:
there's
two
primary
places
where
you
want
to
catch
errors,
either
super
specific
in
a
situation
that
you
can
control
you're,
inserting
into
multiple
tables,
and
something
goes
wrong.
You
need
to
roll
back
those
inserts
or
roll
back.
The
transaction.
That's
very
targeted,
and
I
think
that's
what
you're
talking
about
here
and
then.
E
C
Else
right,
except
at
the
top
most
layer
like
where
you're
replying
to
your
web
requests,
where
you
can
do
something
about
it,
where
you
can
meaningfully
log
that
information
or
you
can
yeah
or
even
better
as
if,
like
lucky
once
client-side
ux
around
what
went
wrong.
You
know
let
the
fbi
do
whatever
it
needs
to
do.
If
you
can't
clean
up
and
let
the
front
end
handle
a
404
or
a
500.
E
So
this
is
going
to
be
my
question
regarding
something
that,
like
he
actually
mentioned,
because
there
is
a
point
where
we
say
that
we
catch
errors
where,
in
the
integration
point
of
like
our
application,
which
is
a
different
thing
from
the
section
that's
going
to
follow,
which
is
where
we
throw
the
errors.
And
it's
a
question
that
I
wanted
to
post
to
the
rest
of
the
panel.
What
is
actually
the
right
behavior,
because,
ideally
my
thought
would
be
to
catch
it
at
the
most
highest
level
at
an
application
level
and
catching
that
error.
E
D
D
D
You
know
that's
that
was
there
was
one
part
of
it.
I
think
that
speaks
to
that
question,
but
but
yeah,
so,
whether
it's
at
what
level
it
is.
This
doesn't
necessarily
matter,
but
I
do
think
that
it.
D
It
is
important
that
you
know
what
you're
catching
you're,
not
just
catching
random
errors
and
logging
them,
because
that
first
piece
of
code,
technically
that
sheena
showed
was
also
swallowing.
The
error
like
that
kind
of
stuff
can
get
you
into
a
lot
of
trouble
in
production
systems
if
you're
just
swallowing
your
errors
or
yeah
like
a
variety.
A
E
Sorry,
what
I'm
hearing
then
from
that
is
that,
in
what
you
just
said,
reiterating
it
again
is
that
levels
should
not
matter
at
any
point
should
not
matter
it's
when
you
catch
an
error
when
you
know
what
you
want
to
do
with
it
pretty
much.
D
D
That's
what
I
think
at
least,
because
we
so
we
we
actually
had
a
problem
like
this
a
while
ago,
where
a
401
era
was
somewhere
along
the
way
being
overridden
by
a
404,
because
something
was
ca
was,
was
catching
and
swallowing
the
401
and
the
service
was
returning
a
404.
D
F
Another
useful
thing
that
you
can
do
you
must
just
check
you
know
with
your
client
or
with
your
data
protection
laws.
Is
you
can
send
your
your
errors,
your
in
that
from
that
central
place
to
your
api,
so
that
if
your
customers
are
actually
getting
those
errors,
obviously
you're
not
getting
them
because
they're
happening
on
the
customers
browsers,
but
for
the
very
important
ones
you
can
actually
send
send
those
through
to
your
api
to
track
them?
F
You
have
to
be
very
careful
if
it's
you
know,
for
example,
a
network
error,
the
net,
the
customers.
B
C
C
C
Finally,
for
example,
if
I
have
a
loader
that
I
switch
on
in
the
try
and
want
to
switch
off
in
the
area,
so
like
that's
a
it's,
a
really
really
good
question
and
I
might
be
reading
too
much
into
it,
but
I've
already
got
the
context
that
that
the
code
that
exists
inside
that
block
is
all
sort
of
related
they're,
either
in
the
same
transaction
or
they're,
either
reusing
the
same
resources
that
you
want
to
free
as
a
part
of
the
finally-
and
I
think
that
that's
that's-
that's
completely,
okay,
right,
because
you're
using
the
language
paradigm
to
you,
know
the
features
of
trying
and
catching
to
clean
up
after
yourself
safely.
C
So
it
is
good.
I
think
the
question
then
becomes
one
of
sustainability
and
just
sort
of
maintainability,
and
I
think
that
was
part
of
schindler's
point
and
please
correct
me
if
I'm,
if
I'm.
D
C
It
incorrectly
so
that
your
code
needs
to
be
idiomatic
in
it
and
full
of
intent,
and
if
that
means
within
that,
try
catch
refactoring
stuff
into
potentially
methods
or
meaningful
methods,
so
that
your
catch
happens
at
a
meta
layer
where
it's
a
whole
bunch
of
additional
sort
of
granular
work
that
happens
in
in
methods
or
subroutines
below
that.
That
can
also
work.
A
Yeah,
so
I
guess
the
the
rule
is
make
it
as
small
as
possible,
but
no
smaller.
Then
you
should
be
okay
and
also
just
to
like
paraphrase
something
jerry
said.
I
I
think
this
is
a
good
paraphrasing
like
if
your
code
breaks
with
an
error
that
you're
not
expecting.
You
actually
want
your
code
to
shout
at
you
and
be
like
oi.
You
fix
this.
You
know
like
that's
what
like
errors,
save
you,
because
they
let
you
know
when
things
are
broken,
so
you
can
go
and
fix
them
yeah.
I
think
that's!
A
That's
probably
it
is
there
anything
else
to
be
said
on
on
catching.
We
didn't
talk
about
asynchronous
stuff
should
should
we
go
into
that
or
should
we
go
on
to
throwing
errors.
C
C
E
Yeah,
that
is
me
all
right.
I
separated
this
into
potentially
three
or
four
things
I
wanted
to
talk
about,
but
I'll
probably
skip
the
second
one.
So
it's
the
why?
How
when
and
some
clean
code,
which
I
appreciate,
because
we've
actually
been
talking
quite
a
bit
about
error
handling,
but
also
maintaining
clean
code
when
you
do
it,
because
it
could
really
get
loud
and
messy
in
your
code,
if
ever
you've
got
try.
D
E
Everywhere,
throwing
everything
everywhere,
so
I
think
a
lot
that
goes
with
error
handling
is
also
being
very
kind
to
how
your
code
looks
like
and
to
that
why
we
throw
things
and
particularly
exceptions.
We
want
to
help
with
debugging
all
right.
It's
supposed
to
what
sheena
just
said
earlier,
that
your
code
needs
to
scream
at
you
when
something
is
wrong.
E
So
you
want
to
be
throwing
these
exceptions
so
that
you
know
that
something
somewhere
has
gone
wrong
and
it
needs
to
help
you
debug
and
find
out
what
the
problem
is
and
let
the
right
people
and
the
right
systems
know
that
something
has
gone
wrong,
which
I'm
sure
is
something
that
we're
going
to
also
cover
in
the
logs
and
stuff.
Like
that
exceptions
in
javascript,
particularly,
are
the
user
defined
right?
E
So
that's
that
the
how
there's
quite
like
about
three
ways
that
you
can
do
that
in
javascript
and
I
say
three
ways
but
yeah:
it
depends
on
what
you
want
to
do
so
just
throw
any
data
type.
So
you
can
throw
a
string.
E
You
can
throw
a
number,
you
can
throw
anything
right
and
then
it
depends
on
how
you
catch
that
when
it
bubbles
up,
you
can
throw
new
error
object
which
accepts
about
four
parameters,
and
that
is
message,
options,
line,
number
and
file
name,
which
are
all
optional,
and
you
can
do
that
to
throw
the
information
that
you
want
to
throw
and
then
the
last
one
is
when
you
want
to
create
customized
exceptions
that
you
can
then
use
everywhere
when
you
want
to
use
it
right,
then
the
when,
which
is
probably
a
very
interesting
thing
in
the
topics
that
we
talking
about.
E
I
heard
or
read
this
thing
where
this
writer
said
it's
always
easier
to
plan
for
failure
at
a
particular
point
in
your
code
than
it
is
to
anticipate
failure
every
way
which
to
me
talked
to
another
thing
that
we
already
mentioned,
where
you
need
to
throw
your
error,
where
you
know
that
a
problem
will
occur
number
one,
and
secondly,
it's
always
easier
to
know
that
area
where
it
will
occur,
instead
of
just
really
really
just
throwing
areas
everywhere,
because
that
also
leads
to
messy
code,
throwing
your
errors
in
utility
functions,
because
the
idea
is
that
whenever
someone
is
using
a
function,
you
might
not
anticipate
some
of
the
parameters
of
the
things
that
they
use
in
those
function.
E
So
it's
always
safe
that,
if
something
happens,
let
us
know
as
a
utility
function
that
something
in
you
has
gone
wrong,
so
that
people
who
consume
that
library,
all
that
utility
function,
that
that
this
particular
thing
has
happened
and
therefore
we
should
be
able
to
handle
it.
Libraries
essentially
or
like
contract-based
anything,
should
make
sure
that
it
tells
the
people
who
consume
those
that
thing
that
library,
when
something
is
going
wrong,
so
that
we
know
as
people
who
are
consumers,
how
we
need
to
handle
it
and
how
to
behave
when
that
thing
happens.
E
The
other
part
to
this
is
errors
only
should
be
thrown
in
the
deepest
part
of
the
application
stack,
and
this
is
why
I
post
the
previous
question,
which
is:
what
is
the
level
at
which
we
need
to
throw
and
catch
errors.
This
context
said
that
the
deepest
part
of
your
application,
which
also
makes
sense
because
that
area
might
not
be
accessible
to,
let's
say
the
front
end
or
any
other
person
who's
consuming
your
application.
E
So
having
to
throw
error
at
that
point
does
the
same
thing
that
I
just
mentioned,
which
is
notifying
us
that
something
has
gone
wrong
in
the
deepest
part
of
our
application
and
then
the
last
part
is
clean
code.
I'm
going
to
be
very
pedantic
and
also
a
response
to
the
question
that
we
had
from
our
user,
which
is
something
that
michael
also
mike,
also
responded
to
in
how
we
need
to
create
code,
but
I'll.
E
Take
it
a
step
even
deeper
that
your
the
idea
of
single
purpose
functions
is
that
your
function
does
one
thing
and
one
thing
one
thing
right:
if
the
try
catch
block
is
not
the
first
element
or
the
first
line
of
your
function,
then
your
function
is
doing
way
too
much.
So,
ideally
things
that,
where
you
throw
errors
separate
that
part
of
logic
of
your
code
somewhere
else,
so
that
it
doesn't
mess
up
the
or
doesn't
pollute
the
rest
of
your
application.
E
Because
all
of
these
things,
where
you're
trying
and
catching
and
doing
all
these
things
could
yeah
mess
up
logic
and
where
you
need
to
debug
and
help
yourself
with
errors,
provide
enough
context
with
your
exceptions.
E
So
if
it's
possible
that
you
could
not
only
write
the
message
but
the
function
that
this
thing
occurred
in
any
other
thing,
that's
not
user
related
data
so
that,
when
it
is
thrown,
it
is
very
explicit
to
the
people
who
are
consuming
that
that
application
or
library
what
has
gone
wrong
and
where
that
problem
actually
is
because
then
it
helps
you
with
your
debugging
process
yeah.
I
think
those
are
my
throwing
fines,
questions,
thoughts.
A
Yeah,
that's
awesome.
I
see
a
bunch
of
questions
are
rolling
in
we
answer
any
of
those
yeah.
Let's
do.
C
It
so
maybe,
let's
start
with
this
one
when
using
try
catch.
Finally,
how
necessary
is
a
finely
clause,
as
opposed
to
just
a
catch.
D
So
can
I
say
something
on
this:
this
used
to
be
used
to
be
one
of
microsoft's
favorite
questions
on
the
certification
exams.
Back
in
the
day
when
I
used
to
write
c-sharp
certification
exams,
so
they
always
used
to
have
a
question
about
with
like
code
snippets
of
try
catch
and
finally-
and
you
had
to
figure
out,
which
was
the
right
one
to
use,
there'd
be
one
with
just
a
try.
Catch
there'd
be
one
with
a
try,
finally,
which
of
them
and
then
be
one
with
a
try
catch.
D
D
F
Yeah,
so
you
mentioned
also
try.
Finally,
so
I
actually
had
a
practical
application
where
I
needed
to
use
that
very
recently,
so
we
are
tracking
jobs
in
progress,
so
we've
got
a
background
worker,
so
I
increment
the
number
of
jobs
as
soon
as
we
pick
the
item
off
of
the
queue
I
try
to
process
it
and
then
finally,
I
decrement
the
number
of
jobs,
but
I
don't
catch
the
error,
because
the
error
handling
for
that
function
is
actually
happening
further
up.
So
I
just
allow
it
to
rethrow.
C
C
Actually,
which
is
really
really
cool
right,
so
perhaps
the
question
that
the
person
wants
to
address
is
is
try.
Finally,
a
code
smell
and
the
answer
is
both
yes
and
no,
and
I
think
the
default
depends.
The
default
is
yes,
if
you're
using
a
try,
find,
I
want
you
to
stop
look
at
what
you're
doing
you've
done.
C
Absolutely
the
right
use
of
the
language
construct
for
that
particular
situation
because
he's
he's
using
it
appropriately,
but
I
think,
start
from
a
perspective
of
like
if
it
if
it
smells
it
probably
is
a
code
smell
like
if
you
stop
to
question
it.
The
answer
is
almost
certainly
yes,.
A
So
it's
almost
like
if
we
have
a
process
running
like
something
some
some
javascript
code
and
we
actually
want
the
error
to
bubble
outside
of
that
process.
So,
like
the
process
needs
to
break,
then
then
it
makes
sense
to
not
actually
handle
the
error
or
something
like
that.
C
C
A
try
where
you've
got
a
whole
bunch
of
inserts
into
a
whole
bunch
of
different
tables
across
different
database
systems,
and
something
goes
wrong.
There
is
no
way
that
you
can
actually
really
recover
from
that.
I
suppose,
if
you
have
a
transaction,
you
could
roll
back,
but
if
it's
a
batch
job,
all
you
can
do
is
clean
up
resources
so
that
things
don't
hang
right.
D
C
C
C
That
phase
is
lying,
but
the
reality
of
the
situation,
as
rudy
pointed
out,
is
that
you
should
only
throw
an
exception
if
you
want
to
inform
somebody
else
that
something's
happened
so
somebody's
using
your
code,
like
a
library
or
a
utility
function
that
you're
responsible
for
that
part
of
code,
but
they
just
want
to
use
it
as
like
a
boxed
function.
That's
when
you
should
be
throwing
errors
right.
F
I
think
the
other
phase
that
a
lot
of
us
have
gone
through
is
using
throwing
of
errors
as
a
control,
a
form
of
control,
which
is
basically
like
a
go-to
statement.
It's
like
you
know,
so
don't
do
that
if
you
do
need
to
go
through
that
phase
to
get
it
out
of
your
system,
try
do
it
on
a
side
project
and
then
you'll
figure
out.
Why
not
to
do
it?.
C
E
My
question
was
going
to
be
throwing
errors
with
messages
versus
error
codes
right,
so
we've
seen
this
being
done,
a
constant
file
with
all
the
codes
and
what
they
mean
and
things
like
that.
So
your
thoughts
on
this.
Why
should
we
can.
F
Okay,
so
if
you
look
at
the
node
errors
that
actually
exist,
you'll
see
that,
because
error
is
an
object,
you
can
put
extra
information
on
it.
F
So
you're
welcome
to
create
an
error,
assign
it
a
code,
but
you
should
always
give
it
a
string
message,
even
if
you're
going
to
be
translating
those
errors
later
on
future,
you
who's
trying
to
debug
what
the
hell
has
gone
wrong
will
definitely
appreciate
it,
and
you
know
you
can
then
use
the
code
to
look
up
the
correct
translation
if
you're
doing
translations,
and
you
can
also
use
that
code
to
handle
it,
regardless
of
if
that
message
changes
over
time.
So
in
this
particular
instance
I
would
say
the
answer
is
both.
C
More
information
right
put
as
much
information
as
possible,
like
the
thing
that
kills
me
is
like
everyone
goes
through,
that
phase,
where
they
then
take
those
error,
messages
and
they'll
refactor
them
out
into
a
constant
file
or
something
right
and
they'll
import.
That
kind
of
file
and
like
we'll
be
so
cool
and
clean.
Our
code
will
be
so
amazing,
seriously.
Control,
f
or
command
f
is
the
simplest
simplest
thing
that
you
could
possibly
use
just
find
that
damn
string-
and
I
don't
want
to
find
the
string
in
a
constants
file,
then
be
like.
C
F
You
do
raise
an
interesting
point
about
if
you
need
to
use
the
same
type
of
error
throughout
your
solution
and
you
don't
want
to
have
the
same
string
spread
out
multiple
times.
There's
this
thing
called
import
and
export
in
javascript
or
const
require,
if
you're
doing
it
on
node,
put
your
error
in
a
separate
file
and
then
we
can
still
jump
to
it
and
see
where
it
gets
used.
So
that's
that's
the
solution
for
that.
Please
don't
copy
paste
the
string
into
700
different
places.
F
C
F
E
F
C
C
D
Should
we
talk
about
this
one
last
question
and
finally,
do
I
really
need
to
add
a
finally
block,
or
can
I
just
continue
with
my
code
outside
of
the
tri-catch
instead
of
using?
Finally,
so
you
can
continue
with
your
code,
but
if
the
catch
runs
and
exits
your
code,
then
that
finally
won't
run.
So
that's
the
point
of
the
final
year.
Right
that
always
happens
is
that
it
happens
whether
the
try
succeeds
or
the
catch
runs.
F
C
Yeah,
so
so
the
finally
to
repeat
again,
the
finally
runs,
irrespective
of
whether
it
passes
or
fails,
but
it'll
guaranteed,
run.
Even
if
you,
you
error
out
completely
and
you
re-throw
the
exception
or
you
return
the
function
or
whatever
the
case
may
be
so
like
it
gives
you
a
third
paradigm.
So
you
could
write
your
try
cash,
the
code
that
happens
after
that
and
then
you
can
both
have
a
catch
that
then
will
re-throw
and
exit
and
finally,
that'll
clean
up,
potentially
and
still
exit,
but
it'll
only
go
into
your
subsequent
code.
D
B
Yeah,
so
so
so,
if
you
throw
in
the
catch,
then
the
code
that
you've
written
outside
of
that
block
will
not
be
reached.
That's
what
we're
saying
right,
but
then,
if
you
have
some
code
that
you
want
to
do
after
this
try
catch
thing,
regardless
of
whether
things
went
well
or
not
like
closing
connection
stuff
like
that,
and
that
should
be
in
the
final
block.
C
D
D
F
Yeah,
I
think
we're
gonna
need
a
whole
meet
up
for
that,
but
I
have
actually
used
es6
classes
to
make
my
own
specific
type
of
errors
that
I
wanted
to
handle
differently
in
the
catch
block,
and
I
set
the
codes
on
them
and
I
added
a
whole
bunch
of
metadata
to
them
so
yeah,
it's
perfectly
fine
to
do
that.
Just
remember
to
extend
the
error
object
and
don't
just
throw
a
normal
object.
Please.
D
You
can
also
use
instance
of
to
find
those
types
of
errors
so
that
you
catch
the
if
you're
catching
a
type
of
error.
You
can
use
instance
of
a
class
to
be
able
to
tell
that
that's
the
area
you're
catching,
but
you
have
to
be
very
careful
if
you're
using
inheritance,
which
is
a
whole
other
javascript
topic.
We
can
talk
about
like
shaking
his
head
because
because
instanceof
does
not
work
if
you're,
if
you
have
subclasses,
does
not
work.
D
C
So
if
you
need
to
keep
state
like
keeping
a
whole
object
that
you're
going
to
have
the
the
code,
the
name
and
a
whole
bunch
of
other
parameters
set
and
then
some
other
things
that
you
can
do
with
it
and
pass
that
around
classes
are
only
primitive
and
you
can
use
object
literal
to
do
the
same,
but
you're
literally
losing
stuff.
Just
for
shorthand.
C
F
C
C
C
F
C
Okay,
so
to
be
so
points
out,
closures
inside
functions,
it's
not
quite
the
same
thing
because
you're
not
then
passing
that
function
reference
around
right,
it's
complicated!
You
can
do
it,
but
if
you've
got
a
function
that
you're
creating
an
instance
of
that
has
state
that's
a
class.
That's
that's
literally
class
is
the
key
word
for
that
idea.
D
C
C
C
Can
everyone
see
this?
Yes,
everyone
can
see
this
okay,
so
this
is.
This
is
what
a
lot
of
this
is
logging
for
people
right,
I'm
going
to
lock.
My
error
seems
reasonable
right.
That's
not!
Logging!
Your
error,
that's
called
swallowing
an
exception
and
swallowing
an
exception
means
that
that
everything
that
you've
done.
All
of
that
error
metadata
that's
happened
is
dead.
It's
gone
forever
and
it's
a
really
really
bad
thing
to
do
so.
Like
please
simply
put
please
don't
do
this.
C
C
C
Using
console.error
and
the
reason
why
you
want
to
propagate
the
error
to
the
log
in
this
case
would
be,
and
we've
discussed
this
the
depth
right,
it's
just
so
that
it's
at
least
still
visible,
so
it
surfaces
on
sort
of
globally
things
that
you
can
do
to
pick
up
global
errors,
one
of
them
being
monkey
patching
console.era
so
that
you
can
do
more
stuff
with
it.
You
can
log
into
a
different
place.
Maybe
you've
got
a
login
configure
configuration
on
on
node.js,
that's
going
to
pick
up
console.errors
and
write
them
to
a
file.
C
C
F
C
100,
so
thank
you
very
much
for
bringing
that
up.
I
didn't
actually
think
that
you
need
to
explain
what
monkey
patching
was
but
you're
right
that
we
do
it's
useful.
It
is
a
very,
very
sharp
tool.
You
will
hurt
yourself
if
you
are
uncareful
or
uncautious
with
it,
but
there
are
like
this
is
how
your
frameworks
work.
This
is
how
express
works.
This
is
how
react
works.
It
monkey
patches
primitives
to
do
additional
stuff
on
top
of
what
it's
doing
right,
but
even
this
is
not
really
meaningful.
C
So,
like
logging
is
probably
the
most
single
most
valuable
thing
that
you
can
do
with
your
errors,
specifically
your
your
your
and
unexpected
errors.
So
we're
not
talking
about
like
cleaning
up
database
connections
so
catching
there
is
actually
not
really
important.
It's
the
final.
So
you
want
to
make
sure
that
you
you
you
clean
up
the
persistent
stuff
we've
spoken
to
death
about
that,
but
for
everything
else,
not
logging
and
not
logging
meaningfully
means
that
you
never
know
that
it's
happening
right,
you're,
just
completely.
C
Oblivious
and
hey,
our
system
is
running
fine
until
something
falls
over
massively
and
like
oh
wait,
we're
actually
getting
a
hundred
thousand
errors
a
day.
So
how
do
you
log
meaningfully,
okay
and
you
log
meaningfully
by
not
doing
a
console.log
or
consult
that
error?
You
get
that
stuff
off
of
the
machine
that
it's
happening
now.
Maybe
it's
writing
to
a
log
file.
That's
going
to
be
log,
rotated
and
shipped
out
in
case
of
server-side
software.
It
is
just
that
easy,
which
is
cool
on
the
client
side,
not
so
much
that's
where
things
are
really
hard.
C
What
is
useful
is
taking
those
abnormal
things
and
trying
to
figure
out
what
people
are
doing
after
the
fact
and
seeing
how
big
each
problem
is,
and
it
doesn't
have
to
be
super
complicated.
You
can
use
something
like
google
analytics
now,
google
analytics
the
reason
why
I
mention
it
is
because
it's
basically
free,
for
all
intents
and
purposes,
if
you
need
to
pay
for
it.
C
You're
in
a
completely
different
ballpark
right,
if
it's
not
google
analytics,
it
could
be
adobe
analytics
or
it
could
be
an
api
that
you
create
yourself
specifically
for
this
purpose
and
there's
nothing
really
wrong
with
it.
It's
just
that
it's
a
little
bit
more
expensive
to
run
a
little
bit
more
complicated
to
deal
with
than
you'd
think,
but
whatever
it
is,
if
you
catch
an
exception,
don't
necessarily
just
lose
that
data
send
it
somewhere
where
later
on.
In
future,
you
can
go
figure
out.
Oh
hey!
C
I
now
know
how
to
find
these
errors,
because
I've
got
context
around
them.
I
can
see
how
big
a
problem
this
is:
I'm
not
going
to
chase
the
thing
that
happens
once
a
day,
I'm
going
to
chase
the
thing
that
happens
a
thousand
times
a
day
and
try
and
fix
that
you'd.
Be
surprised
now
something
to
keep
in
mind
with
this
kind
of,
and
this
is
the
pin
that
I
was
putting
in
for
ryan,
who
was
bringing
this
up
earlier
right.
C
Something
that
I
I
just
want
to
point
out
is
that
doing.
Network
work
in
your
catch
is
sometimes
not
an
amazing
idea,
and
it's
sometimes
not
possible
because
you
can
get
yourself
into
a
tightly
to
loop
of
failure.
If
the
network
is
the
thing
that's
responsible
for
the
failure
or
you
could
fail
in
other
unanticipated
ways,
because
if
this
google
analytics
request
fails
everything
after
this,
all
of
your
careful
work
in
try
catching
and
isolating
stuff
is
all
for
naught
right.
If
this
breaks
the
whole
script
fails.
C
So
this
is
this
is
not
my
ideal.
My
ideal
is
to
just
not
try
catch
in
the
first
place
and
deal
with
the
stuff
globally,
so
try
catch
only
when
you
can
do
something
about
it
right.
Only
when
there's
something
meaningful
for
you
to
do
something
about
it
for
everything
else,
just
put
global
error
handling
in
place
and
there,
depending
on
what
you're
using
there's
different.
You
know
different
mechanisms
for
doing
this,
but
the
one
that
I
put
here
is
the
one
that
you
would
use
for
the
front
end.
C
You
would
add
an
event
list,
node
window
to
check
for
two
things.
So,
firstly,
is
there
an
error?
Did
an
error
happen
in
in
javascript
on
the
page
and
then?
Secondly,
was
there
an
unhandled
promise,
rejection
that
happened
on
the
page,
because
those
are
the
hard
ones
to
to
figure
out
right
and
if
those
happen,
you
get
a
whole
bunch
of
really
really
cool
metadata,
including
literally
the
the
file
and
the
line
that
it
came
from
and
just
a
slight
aside.
C
And
it
can
be
as
simple
as
that.
I
suppose
one
other
thing
that
I'm
not
going
to
show
code
for
because
it's
a
whole
bunch
more
code.
If
you
get
it
to
the
point
where
you're
worried
about
the
impact
of
this
kind
of
stuff.
On
your
front
end,
you
can
just
ship
it
to
your
service
worker
or
ship
it
to
another,
dedicated
web
worker
and
let
that
handle
your
errors
for
you.
So
you
just
tell
it
here's
the
error
and
it'll
batch
them
up
and
send
them
on
mass
to
your
servers.
C
F
While
we
wait
for
the
questions,
any
note
developers
who
are
wondering
how
this
applies
to
them
exactly
the
same
sort
of
format,
it's
a
process
not
on
uncourt
exception
or
unhandled
rejection.
So
you
can
do
the
same
thing
like
mike's
code
here.
C
Okay,
awesome,
so
I
don't
think
there
are
any
any
errors
and
sheena.
D
Forward
so
one
thing
I
just
wanted
also
to
add
to
this
is
the
thing
you
were
talking
about
in
the
beginning.
We
often
just
resort
to
using
console
logs,
but
if
you
think
about
it,
if
you're
just
using
console
logs,
there
is
absolutely
no
way
for
you
to
know
what
the
browser
did
on
some
user's
machine
right.
It's
it's
this
there's
nothing
like
what
what
are
you
gonna
do
ask
them
to
send
you
a
screenshot
of
their
console.
D
C
C
So
ashraf
asking
is
the
throw
catch
not
handled
in
a
separate
thread
like
it
is
in
languages
like
java,
and
the
simple
answer
is
no.
It
is
not
handled
in
a
separate
thread
because
with
javascript,
the
important
thing
to
remember
is
that
you
only
get
one
thread.
That's
it
you
can
make
extras
yourself,
but
it's
a
whole
bunch
of
work
to
do
that.
You
get
nothing
for
free
and
it's
comparatively
newer.
C
Now
the
important
thing-
and
I'm
very
precise,
with
language
here,
is
that
the
context
is
different
between
the
throw
and
the
catch
so
you're,
literally
in
a
different
memory
space.
So
you
can't
necessarily
rely
on
the
same
variables
now
in
a
in
a
simple
example
with
synchronous
code.
That's
fine
in
an
asynchronous
example.
It's
definitely
not
fine,
and
that's
where
things
like
async
await
really
do
a
whole
bunch
of
magic
to
get
you
back
to
the
same
context,
so
that
your
code
can
be
simpler,
but
yeah.
C
Okay,
rethrowing
errors,
somebody
catches
logs
and
rethrows,
so
no
catch
log
and
rethrow
is
definitely
definitely
not
a
great
idea,
rather
add
in
global
global
error,
handling
that
can
just
catch
the
errors
and
throw
literally
like
this
code.
That's
on
screen
right,
just
just
catch
it
at
the
outermost
layer
and
then
lock
it
there
and
it'll
be
more
meaningful.
C
Caching
closing
up
and
cleaning
up
after
yourself
of
all
of
that
stuff
and
then
still
rethrowing
the
exception
so
that
it
bubbles
on
upwards
so
that
everyone
knows
that
it
was
an
unhandled
database
connection
error,
even
though
you've
closed
down
all
of
the
other
stuff
around
it.
D
E
I
don't
want
to
say
the
following
victim
of
the
language,
also
or
like
the
choice
of
exceptions
being
chosen
in
the
particular
language,
for
example,
java
right.
So
if
you've
got
the
most
innermost
class
that
there's
an
error,
any
other
class
that
inherits
that
clause
will
have
to
either
handle
that
error
or
rethrow
it.
So
the
one
that
inherits
above
it
will
then
do
the
same
thing.
So
it's
java
or
meetup,
or
discussion
javascript
meetup.
D
E
Oh
wait:
what's
the
next
topic,
debugging.
E
E
Okay,
all
right,
we
we
can
move
on
because
I'm
also-
maybe
I
forgot
it
because
it
is.
It
is
related
to
vlogging
stuff,
okay,
never
mind,
oh,
when
I
think
about
it,
I'm
just
going
to
interrupt
whoever
stopped.
Aha,
I
just
remembered
cool.
D
D
Okay,
so
recovering
from
errors.
Well,
so
I
kind
of
split
this
up
into
two
things
right
because
on
the
client
there's
two
kinds
of
errors
that
we
get
on
this
server
side,
we
get
lots
of
kinds
of
errors.
You
know
connection
here
as
well,
but
on
the
client,
there's
kind
of
two
kinds
of
areas
we
get
there's
errors
that
are
unknown
areas,
so
they're
the
user's
fault,
the
user
did
something
wrong
and
therefore
there
was
an
error
and
then
there's
the
kind
of
errors
that
it
wasn't,
the
user's
fault.
D
D
I
guess,
but
it's
it's
things
that
can
really
irritate
people
and
put
them
off
your
website.
If,
if
you
don't
do
it
right
because
there's
something
about
that,
I
read
about
earlier
when
I
was
reading
up
on
this
stuff
and
seeing
an
error
on
a
website,
apparently
triggers
your
cortisol
level,
which
is
the
hormone
that
causes
stress
and
the
more
you
stress
out
your
users,
the
less
they're
going
to
want
to
remain
on
your
website.
D
Obviously
right
so
there's
certain
things
we
can
do
to
to
make
sure
that
we
don't
stress
out
our
users
too
much
when
they
make
a
mistake.
Firstly,
showing
them.
Errors
that
are
ambiguous
is
really
can
be
really
irritating.
You
know
just
something
went
wrong:
okay,
but
but
what
was
it?
My
fault?
Was
it
your
fault?
You
know
what
went
wrong.
That
kind
of
thing,
then
using
condescending
or
negative
words
to
explain
the
error
where
it's
like
or
even
symbols.
D
D
I
recently
went
through
the
painful
process
of
trying
to
renew
my
driver's
license
and
then
you
fill
something
in
wrong
and
the
error
appears
somewhere,
but
you
can't
find
it
on
the
page
and
it's
not
like
clearly
visible
and
yeah.
So
so
you
need
to
put
the
errors
in
the
right
place
and
then
lastly
unclear
expectations
from
the
user.
So
you
need
to
tell
them
exactly
what
they
did
wrong
if
they
typed
in
a
password.
That's
too
short,
you
have
to
say
how
many
characters
it
has
to
be.
Not
it's
too
short.
D
It's
simple
stuff
that
that
kind
of
stuff
yeah:
it's
it's
not
really
it's
more
of
a
uxc
thing,
but
it's
also
the
kind
of
thing
that
the
when
you
catch
those
kinds
of
errors.
You
need
to
return
the
right
messages
so
that
the
client
can
display
them
properly
anyway.
But
now,
let's
talk
about
the
unknown
errors,
the
errors
that
something
happened
wasn't
the
user's
fault.
It
may
have
been
the
service
fault.
It
may
have
been
some
other
code
that
you
wrote
on
the
client.
D
We
don't
know
what
it
was.
How
do
we
recover
for
from
that
kind
of
error?
Oh,
firstly,
all
of
the
stuff
we've
been
talking
about
right,
throwing
the
correct
kinds
of
errors
in
order
to
be
able
to
recover
from
them.
There's
certain
errors
that
we
can
retry
so
like
it's
sometimes
safe
to
retry,
for
example,
network
connection
error,
because
if
my
wi-fi
went
down
for
a
millisecond
and
that's
why
my
request
failed
to
the
website.
D
That
should
be
a
safe
thing
to
for
the
client
to
retry
to
call
the
server
again,
because
my
internet
might
be
back
up,
but
on
the
other
hand,
there's
certain
things.
We
can't
retry
because
the
code
we're
calling
might
not
be
idempotent
so
then
we
would
pay
for
something
twice
you
know,
and
that
would
make
that
would
trigger
a
lot
more
cortisol.
D
But
so
let's
talk
about
some
examples
of
what
you
can
and
can't
retry.
So
usually,
if
we
talking
about
http
type
errors,
400
codes
are
the
kinds
of
codes.
You
can't
really
retry.
If
it's
a
403
forbidden,
it
probably
means
no
matter
how
many
times
you
try
it's
going
to
return
403
forbidden,
but
if
it's,
if
it
is,
for
example,
a
503
service
unavailable,
then
maybe
the
service
will
come
back
up
right.
D
So
we
could
try
that
again
so,
but
we
can't
keep
retrying
it
continuously
as
well,
because
we
all
know
what
happened
facebook
the
other
day
and
then
every
everyone
that
was
trying
to
open
their
facebook
app
was
actually
in
a
way
kind
of
ddosing.
The
facebook
servers,
because
the
more
you
retry
the
service
and
available
and
the
service
is
still
unavailable.
D
The
more
chances
are
that
you're
queuing
up
more
requests
on
the
service
and
therefore
making
it
unavailable
for
longer.
Potentially.
So,
how
do?
How
do
you
retry
stuff?
Well,
usually,
what
you
do
is
you'd
have
some
sort
of
back
off.
So
one
of
the
types
of
requests
you
can
retry
is
too
many
too
many
requests.
D
D
So
it's
usually
not
good
to
make
it
an
exponential
back
off
so
try
it
in
two
seconds,
then
try
it
in
four
seconds
then
try
it
in
eight
seconds,
but
it
obviously
would
get
to
a
point
where
retrying
this
thing
there's
no
point
anymore.
Clearly
like
it's,
not
gonna
work
after
we've
gone
into
like
six
16
seconds,
it's
probably
not
gonna
work
and
the
user
is
probably
getting
irritated
because
they're
still
waiting
and
we're
still
retrying.
D
D
So
in
terms
of
things
you
can
always
retry
mentioned
important
events.
So,
for
example,
like
a
get
request
can
always
be
retried
right
because
a
get
request,
shouldn't
change
anything
you
can
always
try
to
get
and
nothing
will
change.
But
if
you're,
for
example,
creating
a
new
payment,
then
you
obviously
can't
always
retry
that,
because
it
might,
it
might
not
be
idempotent,
and
then
people
end
up
paying
twice
for
things
in
terms
of
retries
there's
one
thing:
that's
cool
that
I
learned
about
that.
D
I
think,
because
often
clients
don't
don't
even
implement
retries
for
certain
requests,
but
if
you
tell
them
which
ones
they
can,
then
it's
super
easy
to
implement
that
kind
of
thing
yeah.
So
that's
that's!
On
recovering
from
errors.
It's
not
always
easy
to
recover
from
errors
on
the
client,
especially
because
we
often
don't
know
what
the
user
is
doing,
but
that's
why
the
logging
thing
is
pretty
cool.
D
D
So
usually
trying
to
reproduce
the
error
in
your
environment
is
is
the
way
I've
debugged
clients,
ideas
before
I'm
not
sure.
If
anyone
else
has
any
other
ideas
in
terms
of
that,
but
yeah
trolling
through
logs
and
trying
to
replicate
what
the
user
did
is.
C
I
think
an
important
point
to
raise
is
that
browsers
are
also
different
right,
particularly
if
you're
looking
at
finding
issues
that
you
spot
a
client
side.
You
might
have
somebody
that's
complaining
about
something
breaking
and
you
can't
assume
that
they're
running
the
same
browser
that
you've
tested
on
and
even
if
they
are.
You
can't
assume
that
they're
running
the
same
version,
because
different
browsers
have
different
different
browser
versions,
have
different
facts.
D
D
D
That
also
brings
us
back
to
the
logging
a
little
bit
right
like
you,
that's
the
kind
of
stuff
you
need
to
log,
and
I
know
a
few
months
ago
when
we
spoke
about
privacy
and
the
how
dangerous
the
user
agent
string
is.
D
But
I
think
this
is
one
good
you
use
of
the
user
agent
string
is
that
if
you
had
that
in
your
error,
log
you'd
be
able
to
figure
out
what
browser
version
they
were
using
and
what
device
they
were
using
in
order
to
help
the
user
not
experience.
The
error,
which
is,
I
think,
what
the
use
agent
string
was
meant
for
not
invading
people's
privacy.
C
Yeah
and
if
you
end
up
using
google
analytics
or
trying
google
analytics,
it
gets
a
whole
bunch
of
that
stuff
for
free.
You
don't
have
to
write
it
right.
You
get
to
know
which
browser
which
browser
it
came
from
roughly
where
it
was
versions.
If
they're
available
you
get
groupings
of
areas
together,
so
you
can
with
other
user
behavior
anonymized
so
that.
C
C
E
Any
more
questions,
yes,
retrying
strategies,
I
think
in
most
of
my
career,
this
has
always
happened,
not
the
way.
Anyone
who
has
either
written
it
or
anyone
who's
experiencing.
It
was
happy
with
right
from
sending
emails
that
people
then
afterwards
received
multiple
emails,
because
retries
happened
and
then
million
messages
went
to
people
saying
exactly
the
same
thing.
E
What
is
the
go-to
based
on
people,
like
maybe
they've,
had
experience
with
this,
because
I
haven't
as
much
as
I'd
like
just
like,
observing
the
the
standard
or
like
what
you
need
to
like
do
when
you
have
to
retry
certain
transactions.
That's,
maybe
writing.
E
Okay,
maybe
not
retrying
right
into
the
database
as
jerry
just
mentioned,
but
like
sending
emails.
For
example,
what
strategies
have
other
people
applied
in
the
past,
even
though,
like
you
know,
and
have
they
worked
well?
Did
you
feel
confident
when
you
were
writing
that
code,
that
this
is
going
to
do
what
you
think
it's
going
to
do?
What
do
you
do
in
those
situations
when
you
have
to
oh
not
have
to
but
want
to
retry.
A
You
gotta
track
of
stuff
so
like
keep
track
of
the
fact
that
you're
about
to
send
that
email,
then
keep
track
of
the
fact
that
you
just
sent
that
email
and
it
happened.
And
then
you
do
the
same
thing
with
the
next
email,
but
that
could
be
maybe
expensive
in
some
other
ways,
because
it's
so
stuffed
down.
But
it's
not
like
a
big
deal.
I
think
that
that
would
make
me
feel
very
sure.
D
Yeah
so
we're
a
while
ago,
I
had
to
implement
one
of
these
things,
eventing
things
that
sends
emails
to
quite
a
few
users
every
day
at
a
specific
time,
and
we
had
to
make
sure
that
the
emails
were
only
ever
being
sent
once
to
those
users
and
and
that's
yeah
you
you
have
to
keep
track
of
where
in
the
process
you
are
and
what
happened
at
that
point
in
the
process.
So
you
can
pick
up
and
and
try
again
from
that
point
in
time.
D
So
like
adding,
adding
statuses
to
things,
helps
a
lot
and
yeah.
You
just
have
to
make
sure
your
processes
are
idempotent.
I'm
not
sure
how
you
test
it
to
make
sure
that
it
never
happens.
I
mean
I'm
pretty
sure
we're
only
sending
one
email
per
day
per
person.
D
But
but
you
never
know,
I
mean
no
one's
complained
yet,
and
our
customer
support
people
are
generally
very
much
on
our
case
when
something
goes
wrong.
D
No
news
is
good
news
yeah,
but
it
has
until
recently
it
did
prevent
us
from
from
trying,
at
certain
other
things
like
adding
in
an
extra
like
notification,
push
notification
or
email,
or
things
like
that,
because
we
we
were
worried
about
our
states,
but
then
recently
we
started
refactoring
that
so
this
data
make
a
bit
more
sense
now,
so
we're
hopefully
doing
even
better.
E
A
It
looks
like
they
aren't
any
more
questions
from
the
audience.
Is
there
anything
else?
That's
from
this
room
good
to
go.
E
A
I
should
have
said
something
I
think
we
can
bring
that
up.
I
don't
know
I
don't
know
about
their
data
cues.
Does
anyone
know
about
their
data
keys.