►
From YouTube: GitHub Quick Reviews
Description
Powered by Restream https://restream.io/
A
All
right,
hello,
friends,
let's
start
with
the
unknown
exception
handler
that
jan
suggested
jan
you
want
to
talk
about
it.
B
With
this
proposal
we
see
today
when
people
are
kind
of
hosting
the
the
runtime
with
say
rappers
or
you
know,
when
or
in
designers,
when
there
is
user
code
that
might
be
running,
and
you
know
there
is
no
way
how
they
can
reliably
handle
exceptions
from
all
exceptions
from
that
user
code
in
particular,
they
are
not
able
to
handle
exceptions
that
you
know
have
thrown
on
new
threats,
and
you
know,
historically,
we
had
app
domains
for
this
and
we
also
had
the
unmanaged
hosting
apis
for
this.
B
A
B
B
A
B
A
Yeah,
basically
so
we
have
this
generic
exception
called
canceled
event
arcs,
where
the
idea
is
you,
you
basically
have
a
boolean
cancel
that
the
handler
can
set,
and
that
is
the
canonical
way
to
say
basically
stop
propagating
this
guy
or
stop
the
action
or
whatever
the
the
thing
does
right
and
so
yeah.
We
would
just
insert
that
in
between.
I
assume,
under
the
exception
of
androx,
just
derives
some
exception
right,
or
does
it
derive
from
something
weird
that
become.
A
A
A
B
A
B
Another
kind
of
pattern
is
the
for
the
tasks
we
have
very
similar
api
and
for
that
the
property
is
read
only
and
there
is
you
know,
methods
to
kind
of
set.
It.
A
B
A
That's
the
observed
set
observed
thing
I
mean
in
this
case
the
property
seems
fine.
I
mean.
A
B
A
D
D
The
the
is
terminating
property.
Does
that
remind
me:
does
that
mirror
something
that's
already
in
full
framework.
D
B
B
You
know
it
it
kind
of
originated
in
the
dotnet
framework,
1.0
days
when
the
unhandled
exceptions
were
handled
in
some
situations
in
not
necessarily
1.0
the
unhealth
exceptions
on
finalizer
threats
were
ignored,
for
example,
and
you
know
if
the
exception
was
about
to
be
ignored,
the
is
terminating
was
set
to
false.
A
B
A
E
Yeah,
so
this
is
when
we
remove
system.net.connections,
we
do
two
features
from
sockets
hp
handler
that
depended
on
it,
and
then
we
added
one
back,
which
was
the
connect
callback,
because
bing
really
wanted
it,
and
now
it
turns
out
that
bing
really
wants
this
too.
E
The
plain
text
filter
feature
the
capability
here
is
to
allow
you
to
basically
hook
the
stream
at
the
point
above
tls.
In
other
words,
whereas
connect
callback
lets
you
hook
the
raw
connection
on
the
wire.
This
capability
allows
you
to
hook
it
on
top
of
tls,
so
that
you
see
the
actual.
You
know
hp
protocol
bits
either
hb
1.1
or
hb2.
E
You
can
see
the
arguments
that
the
context
object
has
is
the
the
plain
text
stream,
which
is
the
underlying
stream,
that
we
give
you
and
you
can
wrap
that.
However,
you
want
and
return
your
own
stream
to
us
or
return
that
stream
to
us.
If
you
want,
we
also
give
you
a
little
bit.
We
also
give
you
the
hp
version,
which
will
always
be
one
one
or
two,
although
in
the
future
maybe
three
and
the
hp
request
message
in
case
you
want
to
take
some
action
off
of
that.
E
That's
the
we
also
give
you
the
hp
request
messaging
for
the
connect
callback
so
and
the
the
callback
itself
is
is
again
very
similar
to
the
connect
callback.
Basically,
you
give
you
the
context
cancellation
token.
You
give
us
back
a
stream,
so
the
biggest
concern
I
have
here
frankly,
is
the
naming
like.
I
think
some
of
the
naming
here
is
not
great.
The
original
naming
was
just
plain
text
filter.
I
put
a
few
comments
in
the
alternative
design
about.
You
know
issues
around
naming.
E
E
E
A
F
We
have
http
version
here
and
non-http
request
message
properties.
Would
it
make
sense
to
just
rename
that
to
version
or
are
we
trying
to
disambiguate
something.
E
E
E
F
I
mean
it,
something
like
request
version
could
also
work,
and
I
think
what
you're
trying
to
get
at
with
this
version
is
the
request.
Message
has
a
version,
but
then
the
client
actually
chooses
which
outgoing
version
to
try.
So
this
could
be
different
from
what
the
user
asks
for
right.
E
Yeah,
exactly
the
the
and
the
user
may,
for
example,
specify
well
now.
We've
got
version
policy
on
the
request
message
as
well,
so
your
you
know
the
version
info
that
you
give
us
on
a
request
message
might
be
something
like
you
know,
2.0
or
lower,
in
which
case
you
know
by
the
time
we
get
to
this
point
and
we've
actually
established
the
hp
version
here
definitely
can
be
different
than
the
version
as
specified
on
the
request.
E
F
F
I
mean
it's:
it's
negotiated
when
you're
using
tls.
Otherwise
it's
just
kind
of.
F
I
guess
it's
a
negotiation
between
the
user
and
the
sockets
handler
still,
so
I
think
that
would
be
fine.
A
F
A
E
I
don't
think
it's
significant.
I
usually
see
it
as
one
word.
E
But
that's
just
sort
of
a
that's
kind
of
a
what's
the
return.
That's
just
that's
like
a
usage
that
has
been
adopted
by,
I
guess
various
security
folks,
mostly.
D
G
G
E
A
A
E
A
A
F
F
F
Yeah
I
mean,
I
think,
that's
what
plain
text
means,
at
least
when
I
think
of
cryptography,
but
I
know
we
talked
about
using
raw,
also.
A
Yeah,
I
guess
unencrypted
or
raw,
would
it's
kind
of
the
same?
I
guess
but
like
yeah,
I
guess,
if
it's
not
actual
text,
if
it's
a
binary
blob,
then
you
go
into
the
cryptographic
definition
of
the
term
plain
text,
meaning
unencrypted
with
that
might
not
be
very
intuitive
for
people.
A
F
Request
message:
I
can't
remember
what
we
called
it
on
the
last
api,
but
it's
really
the
first
request
message
that
initiated
the
connection
yeah,
so
it
could
be
confusing
to
just
see
a
request
message
there,
but
I
think
we'd
want
consistency
with
what
we
chose
last
time,
which
I
think
was
just
request
message.
We.
E
Did
call
it
just
request
message
frankly,
I,
like
initial
request
message
better,
because
my
concern
here
is
that
the
people
make
some
decision
based
off
the
request
message:
that's
not
appropriate
because
they
somehow
are
forgetting
that
that
they're
going
to
be
lots
of
requests
that
are
sent
over
this
connection.
So
initial
request
message,
kind
of
conveys
that
better,
if
we
don't
mind
sneaking
in
a
change
to
the
other
feature
as
well,
I'd
be
happy
to
change
it.
H
E
It's
not
so
much
that
you're
going
to
make
a
different
decision.
The
point
is
just
to
reinforce
that
any
decision
you
make
based
off
this
context
is
you've
only
got
access
to
the
initial
message
here.
There
will
be
subsequent
messages
that
you're
not
going
to
get
access
to
because
you've
already
established
the
filter,
and
so
the.
E
To
convey
the.
A
F
Well,
it's
it's
the
first
message
that
caused
this
new
connection
to
be
created.
So
one
thing
this
you
know
just.
H
H
A
F
I
think
the
previous
api
was
a
little
clearer
because
the
callback
was
called
like
connection
callback
or
something
like
that,
and
but
in
this
case
it's
it's
not
clear
by
the
naming.
So
initial
request
message
makes
sense
to
me
here.
A
A
E
Can
we
sneak
in
making
the
connect
context
match
the
request
message,
naming
too.
E
A
E
E
A
A
Yeah,
because
the
new,
because
the
the
socket
hp
connection
context,
is
relatively
short
right
and
then
you
have
connect
callback
and
then,
in
this
case,
first
of
all,
you
don't
use
the
norm.
Callback
on
the
property.
You
just
call
it
plain
text
stream
filter,
but
then
also
the
the
class
name
is
fairly
long
winded,
and
so
I
was
just
wondering
whether
it
makes
sense
to
shorten
it.
A
A
E
F
E
E
D
E
F
Can
we
add
a
cancellation
token
to
this?
I
don't
know
if
the
windows
api
supports
it.
C
I'm
assuming,
I
think,
on
windows,
it's
just
overlap
stuff,
so
presumably
we
could
make
that
work.
Yeah.
F
Agree
and
instead
of
a
byte
array,
take
a
memory
read
only
memory.
A
C
H
C
Actually,
just
opened
an
issue
yesterday
that
it
actually
does
it's
even
docu,
like
the
the
synchronous
send
file
as
well
as
begin
send
file
are
both
documented
to
allow
null
for
that
first
argument,
so
our
annotation
there
and
and
dotnet
framework
actually
does
allow
null,
and
I
have
a
pr
out
to
fix
the
bug,
we're
in.net
core.
We
accidentally
don't
so.
C
B
C
We
we
made
that
work
on
unix,
and
then
it
just
so
happened
that
we
forgot
to
include
the
annotation
which
we're
not
gonna,
fix
and
done
at
five,
because
it
doesn't.
I
can't
imagine
anyone
actually
caring
to
pass
nellier
in
the
first
overload.
I
could
hypothetically
see
a
scenario
where
someone
wanted
to
use
the
second
one
instead
of
calling
send
twice
or
something
for
two
different
buffers,
but
yeah.
C
G
C
A
E
A
A
C
F
C
Started
adding
the
equals
defaults
after
we'd
already
added
a
bunch
of
apis
with
cancellation
token,
so
I
think
most
of
the
newer
ones
we've
been
defining
have
the
equals
defaults
and
ones
we
defined
prior
to
some
date.
Didn't
we
started
going
back
in
some
cases
and
adding
them,
but
we
haven't
done
any
kind
of
consistent
audit.
A
C
A
That's
right:
we
just
went
again
to
zero,
like
we
like,
I
think,
starting
a
few
weeks
ago.
We
drove
it
to
zero
and
now
pretty
much
every
meeting
is
one
or
two.
So
far
so
wow
yeah,
it's
pretty
good,
there's
a
few
bigger
ones
coming,
though,
so
there's
the
the
binary
data
that
crystal
was
talking
about.
There
is
a
what
was
the
other
one.