►
From YouTube: GitHub Quick Reviews
Description
Powered by Restream https://restream.io/
A
B
Excellent,
so
this
is
a
request
from
the
orleans
team.
They,
they
marshall
exception
objects
back
and
forth,
to
represent
failures
in
their.
I
believe
they
call
them
grains
communication
mechanism,
the
general
one,
one
of
the
things
that
we
said
a
while
back
was
that
when
we
brought
exception
types
from
that
full
framework
into
net
core,
we
tried
to
make
all
of
those
types
serializable.
B
This
one
was
missed
because
it
didn't
in
dot
net
framework,
implement
the
proper
serialization
constructors,
so
it
just
never
got
migrated
to
to
the.net
core
like
I
can
be
serialized
list.
One
of
the
things
that
we
said
more
recently
was
for
exception
types
that
exist
both
in
full
framework
and
in
dotnet
core.
We
would
still
allow
them
to
be
marked
and
serializable,
even
though
we're
not
allowing
other
exchange
types
to
be
binary
format
or
serializable.
B
If
I
misunderstood
our
conversation
from
a
few
weeks
ago
on
that
point,
please
correct
me,
so
this
request,
basically,
is
hey,
allow
this
exception
type
to
be
serializable
and
dotnet
core,
just
like
it
is
in
full
framework.
There
is
a
caveat
here,
which
is
the
serialization
mechanism
that
this
uses
in
that
full
framework
uses
something
called
a
safe,
serialization
manager,
which
was
really
meant
to
allow
serialization
to
take
place
in
partial
trust
environments.
B
That
infrastructure
does
not
exist
in
any
capacity
in.net
core,
which
means
that
we
can't
use
that
infrastructure.
We
have
to
use
the
typical
serialization
infrastructure.
The
consequence
of
this
is
that
the
payload
for
this
type,
once
it's
serialized,
is
incompatible
between.net
core
and
on
that
full
framework.
That
is,
if
you
serialize
it
in
core,
it
cannot
be
deserialized
in
full
framework
and
vice
versa.
A
So
now
I'm
confused
so
everything
you
said
until
this
point
makes
sense
to
me,
except
when
you
say,
because
I
mean
I
assume
that
orleans
similar
to
many
other
customers.
They
do
a
partial
migration
right.
They
don't
do
everything
at
once,
and
so,
presumably
when
they
have
some
grains
running
in
dotnet
framework,
some
grains
running
in
core
and
they
have
failures
across
those.
They
want
to
still
have
a
sensible
behavior.
Where
you
can.
You
know
catch
exceptions
and
propagate
them
as
as
as
normally
so.
B
They
they
want
to
be
able
to
utilize
their
existing
infrastructure
to
be
able
to
to
be
able
to
marshal
exceptions,
but
I
I
told
them
that
this
would
only
work
if
both
grains
are
core
or
both
grains
were
full
framework.
And
again
they
told
me
that
that
was
acceptable
from
their
point
of
view.
A
B
A
Execution
they
have
is
consistently
on
core
consistently
on
full
framework.
So
then,
let's
say
that's
okay,
then,
but
then
my
next
question
would
be
if
we
believe
that
that
is
the
right
behavior
for
the
stuff
that
runs
on
core.
Why
would
this
realizable
guideline
only
apply
to
exceptions
that
exist
in
full
framework.
B
It's
the
guideline
was
to
allow
code
that
ran
the
the
guideline
is
to
allow
you
to
write
code
that
is
net
standard
compliant.
I
believe
jeremy,
please
please
chime
in
if
I'm
mistaken
here,
but
the
idea
is,
if
you
follow
the
this
is
how
exception
should
be
serialized
guidance,
then
you'll
create
something
that
is
valid
both
on
core
and
on
full
framework
for
things
like
app
domain,
remoting
or
marshalling,
but
because
app
domain,
marshalling
and
remoting
don't
exist
on
core.
B
What
we
were
saying
is
that
exception
types
that
exist
only
on
core
don't
need
to
be
marked
to
serializable,
because
there
was
never
any
hope
of
those
things
ever
being
used
in
code
that
crosstap
domain
boundaries
in
the
first
place.
A
Presumably
they
do
their
own
catch
exception,
binary
format,
exception
and
then
somehow
translate
that
palette
on
the
other
side
and
then
do
the
visualization
there
right.
So
they
don't
use
remoting,
but
they
use
effectively
their
own
version
of
remoting
right.
So
I
guess
my
question
is:
if
we
say
yes
to
this,
how
can
we
not
say
yes
to
the
next
exception
that
orleans
on
core
happens
to
throw
that
never
existed
on
full
framework.
B
You're
you're
right,
it
is
absolutely
a
slippery
slope.
One
of
the
things
that
I
linked
to
in
this
issue
is
like.
We
need
an
answer
for
how
do
I
just
send
ex?
How
do
I
serialize
exceptions
safely
without
using
binary
formatter?
That
infrastructure
doesn't
quite
exist
yet
because
what
we
tell
people
is,
if
you
want
to
do
this
safely
exception.2string
and
send
the
string
across
a
wire,
that's
the
only
truly
safe
way
to
do
it.
A
So
I
guess
then,
then
your
proposal
is
exceptions
are
somehow
serializable
on
core
and
it
might
be
as
simple
as
calling
to
string
on
it.
But
if
the
exception
happens
to
exist
also
in
full
framework,
then
the
way
by
which
we
do
that
is
is
binary.
Formatter,
because
that's
the
only
two
thing
that
exists
in
both
places.
B
Yes,
that
was
the
guidance
that
we
came
up
with
a
few
weeks
ago,
because
we
in
in
the
obsolution
document
that
I
had
sent
around
sent
around,
we
had
said
that
we're
not
going
to
mark
any
other
types
as
serializable
from
here
on
out
going
forward.
But
we
carved
an
exception
into
that
rule,
which
said
that
exceptions
are
special,
because
there
is
a
a
way
of
generating
exception,
derived
types
and
the
way
of
generating
them
involves
using
the
proper
serialization
semantics.
A
A
B
A
The
only
safe
way
to
do
this
is
to
string,
but
then
you
basically
use
the
you
know.
The
actual
exception
object.
If
you
will
right
you
get
it,
you
get
a
different
exception
object
with
a
different
type,
where
maybe
that
is
the
property
of
something
right,
but
like
you,
no
longer
get
the
actual
types,
and
so.
A
Right
but
like
no
matter
what
that
is,
it's
basically
different
from
what
orleans
does
today.
So
like
you're,
basically
saying
what
orleans
does
today,
you
know
they
do
that
because
they
seem
to
support
both
sides,
but
eventually
you
would
accept
willing,
expect
orleans
to
either
accept
the
fact
that
not
all
exceptions
will
be
binary
formidable
or
that
they
have
to
move
to
something
else.
B
Right
so
as
as
we
stop
generating
packages
that
target
net
standard,
as
we
generate
packages
that
target
like
net
500
and
above
only,
those
packages
will
not
have
serializable
exceptions,
which
means
that,
yes,
they
their
framework
will
need
a
different
mechanism
of
shuttling.
This
information
back
and
forth.
This
is
not.
This
is
not
future
proof
for
them.
Correct.
A
B
Yes,
because
right
right
now,
they're
also
running
into
an
issue
where
asp.net
for
bids
binary
formatter
by
default
now
in
dot
net
five,
we're
going
to
roll
that
out
to
other
project
types
in
the
future
and
they're
they're
already
going
to
be
in
a
situation
where
they're
now
asking
their
customers.
Please
configure
your
application
to
opt
into
this
thing
that
the
runtime
team
is
telling
you
not
to
use,
so
they
we're
going
to
have
to
have
a
come
to
jesus
moment
anyway.
A
C
It
seems
fine,
we
do
need
to
understand
what
the
guidance
will
be
going
forward
and
like
I'm
personally
fine
with
saying
exception,
all
exceptions
get
marked
as
serializable,
because
that's
what
we've
been
saying
for
a
while,
but
it
does
become
if
they
want
it
for
any
other
type.
Then
that's
a
much
harder
discussion
to
have
just
like
it
always
has
been,
but
yeah.
So
really
it's.
We
need
to
figure
out
what
the
guidance
is
going
forward,
because
this
has
already
shown
that
there
are.
B
Yeah
and
and
like
there
there's
an
existing
issue
right
now
with
memory
stream
and
and
what
is
a
data
contract
serializer
that
we're
kind
of
pushing
back
on,
because
we
really
really
really
don't
want
people
to
to
send
private
field
information
across
that
boundary.
But
if,
if
you
look
in
the
linked
issue
here,
the
orleans
team
actually
has
been
pretty
good
about
saying
like
look.
If
we,
if
we
do
have
a
new
technology,
that's
meant
only
for
serializing
exceptions
and
and
absolutely
nothing
else.
B
Just
that
here
are
the
qual
here,
the
characteristics
that
we
would
like
that
thing
to
have
so
we're.
I
think
those
talks
are
productive
right
now,.
B
Is
there
anything
that
we
need
to
do
in
order
to
say
like
look
these
these
payloads
are
not
compatible
across
runtimes.
A
We
have
gone
out
of
our
way
to
make
it
work
in
scenarios
that
have
unblocked
people
that
we
care
to
unblock,
but
it's
not
something
that
we
generally
like
say
we
support
right.
I
mean
it's
something
where
we
you
know
we
try
not
to
break
it
when
we
had
support
for
it
in
the
past,
but
we
also
not
necessarily
going
out
of
a
way
to
make
that
possible.
I
guess.
A
B
A
A
Yes,
I
guess
that's
the
point
right
so
like
if
it's
just
oh
somebody
in
dot
net
core
felt
like
they
reordered
some
filter
readability,
then
I
would
say:
yeah,
let's
undo
that
that's
not
adding
value
right,
but
if
it's
like,
oh,
you
have
to
bring
back
a
whole
bunch
of
infrastructure.
To
do
that,
then
that's
very
sad,
but
I'm
also
surprised
that.
A
A
D
A
A
A
D
Yeah,
so
this
is
the
the
api
that
we
have
in
winforms
that
we
brought
up
before
that
actually
mutates
string.
D
D
So
these
are
the
proposed
apis
to
allow
people
to
actually
specify
that
they
want
any,
possibly
mutated
string
out
of
it
and
they're.
Basically,
just
taking
these
when
you
say
when
you
mutate
straight,
like
you
actually
mean
system,
dot
string
is
mutated.
Yes,
sorry
you
weren't
in
that
one.
No,
that
sucks
yeah,
it's
pretty
pretty
much
so.
D
D
You
know
I
I
added
span
overloads
and
that's
where
I
actually
ran
into
this
when
I
was
actually
doing
some
performance
work
and
all
that
I'm
like
really
yeah.
We
we
mutate
the
string
and
the
span
ones,
don't
let
you
do
what
they
throw.
If
you
have
the
flag.
D
That
mutation
thing
does
is
like,
if
you
happen
to
have
one
of
the
other
flags
that
will
truncate
the
text.
There's
the
puts
the
three
ellipses
on
right
or
the
ellipses
of
the
three
dots
and
there's
an
option
to
get
back
whatever
the
framework
we
weld
up.
D
Sorry
windows
actually
put
out
or
the
common
control
did
so
to
make
this
relatively
easy
for
people
to
do
and
and
migrate
to
they're,
just
basically
tacking
on
the
output
string
on
the
end
of
the
existing
apis
and
if
you
scroll
over
there,
that's
that's
what
you
have
at
the
end
of
those
apis
is
just
they've
just
got
for
the
ones
that
were,
I
didn't
add
the
I
added
the
one
that
took
all
the
arguments
and
that's
the
only
one
I
did
and
then
then
added
ones
that
had
out
strings
and
then
an
output
text
buffer
that
people
can
use
or
pass
in,
and
you
know
the
string
is
always
going
to
be
the
same
size
or
lower.
D
So,
that's
that's
something
that
we
can
check
with
the
span
case
and
it's
it's
fairly
straightforward
to
implement
and
with
it
by
having
the
span
on
the
end
of
it.
It
also
allows
people
to
if
they
care
to
to
use
the
same
the
same
spain
buffer
on
the
input
in
the
output
for
those
that
really
want
the
advanced
scenario
which
the
native
windows
api
supports.
Right.
D
A
D
A
D
So
in
these
particular
cases,
basically,
what
we
would
do
is
we'd
be
looking
for
that
we
would
be
setting
that
flag
implicitly,
because
you
know
ideally
we'd
get
rid
of
the
flag
right
completely,
and
you
know
these
ones
will
say
well
we'll
set
the
flag
which
only
matters
in
a
couple
cases
right.
So
there's
the
two
cases
where
it
actually
does.
The
ellipses
thing
is
where
the
only
case
it
cares
about
those
things.
B
D
Oh,
we
don't,
you
know,
you're
passing
it,
we
don't
mutate
the
span
ones
and
we
want
to
do
the
same
thing
to
the
other
ones
right.
We
will
no
longer
tape
the
string,
but
we
need
something
to
replace
it
with.
So
you
can't
use
the
span
stuff
if
you
want
to
right
now,
because
we
don't
have
a
solution
for
you.
If
you
want
the
output
string,
I
figured
it
was
better
to
do
that
and
then
you
know
bring
this
thing
in
as
a
secondary,
a
follow-up
rather.
B
A
D
They
already
existed
this
particular
api.
So
then
I
can,
you
know,
hope.
Hopefully
what
I
can
do
is
just
in
six.
I
can
remove
the
flag
and
throw
if
it
comes
in
that
with
that
flag,
because
we
just
do
a
cast
of
these
things
right.
The
inputs
right
there
they're
actually
defined
to
the
same
things
that
windows
uses.
D
Well,
we're
going
to
reject
the
flag
just
because
it's
it's
no
longer
there
and
we
don't
want
to
confuse
people.
You
know
have
them.
You
know,
use
the
actual,
define
directly
thinking
that
that's
necessary
because
you
know
the
casting
whatever
it
is.
If
it's
I
don't
know
what
the
value
is.
Let's
say
it's
16
or
whatever.
A
Right
yeah,
I
don't
think
we
care
about
that,
I
mean
so
I
guess
then,
okay,
you
would
just
so.
We
could
just
basically
blindly
obsolete
the
flag
and
say
if
you
really
want
the
output
string,
call
the
apis
that
give
it
to
you,
but
you
still
don't
have
to
pass
on
the
flag
because
by
calling
the
out
methods,
you're.
D
You're
you're
opting
for
we'll
do
that
magic
for
you
because
there's
it's
like
I
said,
there's
only
the
it
only
makes
any
difference
in
the
one
case
where
you,
the
others,
the
two
flags
that
do
the
the
truncation,
and
that's
not
really
that
common.
So
but
you
know
we'll
we'll
put
it
on
where
it's
necessary,
where
there
could
be
a
mutation
and,
in
the
other
cases
we'll
just
pass
back
out
the
string
we
got
in
and
the
span
that
we
got
in
right.
Just
as
a
that's
just
an
internal
optimization.
A
D
A
I
see
okay,
then
nevermind
then.
C
So,
from
the
guidelines
perspective,
the
what
we
say
is
something
like
the
output
parameter
or
the
output
buffer
should
be
the
first
parameter
after
the
input
buffer,
meaning
that,
instead
of
going
at
the
end
where
they're
proposed
the
guidelines
would
suggest
they
go
after
text.
C
So
you
would
get
draw
text
device
context,
read-only,
span
of
char
text,
comma
span
of
char
destination.
It
also
says,
prefer
the
name
destination
for
a
single
output
buffer.
Okay,
we
can
say
that
it
doesn't
fit
in
context
here,
especially
because
there's
this
idevice
context
that
goes
before
the
text,
and
so
this
is
already
not
quite
looking
like
buffer
patterns,
but
I
just
thought
I
would
say
what
it
is
that
we
wrote
down
of
where
we
think
that
output
spans
go
in
in
signatures
in
general.
A
A
C
D
A
I
mean
I
have
to
say
like
I
to
me
this
kind
of
reminds
me
of
the
general
contention
that
we
have
between
consistency
across
patterns
like
sorry
across
apis
with
a
singular
pattern
and
just
being
consistent
in
a
particular
context.
They
already
are
whether
it's
a
type
or
a
method
group
right
in
this
case
it
seems
inserting
them
right.
After
that
seems
more
in
noise
and
and
and
churn
that
actually
makes
things
less
usable
than
more
usable.
A
C
I
guess
one
of
the
things
I
don't
understand
is:
why
is
it
void
with
an
out
string?
Oh
because
you
already
have
a
you
would
be
varying
on
the
return
yeah
based.
C
D
D
C
Things
a
lot
easier
right
so
but
that's
that's
the
general
expectation
that
we
have
for
buffer
writing
operations,
but
I
I
agree
that
it
looks
sort
of
natural
here
at
the
end.
I
just
had
the
the
bell
ringing
in
the
back
of
my
head.
That
said,
this
isn't
canonical,
and
so
I
I
looked
up
the
written.
A
Seems
reasonable
anything
else
I
mean,
like
I
just
messed
with
the
text
in
my
buffer
to
just
align
the
parameters
a
little
bit
more
and
it
looks
consistent
to
me.
C
The
yeah
we
have
a
pro
do
prefer,
I
think,
is
how
we
wrote
the
guidance
that
a
single
output
buffer
should
be
named
destination.
A
C
Right,
I
mean
the
the
thing
that
is
confusing.
All
of
this
is
the
fact
that
we're
having
to
introduce
an
outstring
because
of
changing
a
thing
that
was
doing,
modify
in
place
to
returning
and
that
we
can't
add
a
return
type,
so
we
are
effectively
an
uncharted
territory
here.
So
this
this
may
be
what's
proposed,
may
be
the
most
reasonable,
given
what
it's
trying
to
change
about
the
api
shape.
C
D
D
D
D
Well,
from
a
on
the
windows
standpoint,
when
you're
going
to
get
a
device
context,
yes,
that's
how
you
get
the
the
screen
dc's
you
pass
in
null
for
the
for
the
h1
that
you're
getting
the
dc
from,
but
that's
just
an
internal
thing.
A
D
C
Given
the
shape
that
ex
that
exists
right
with
it
that
we're
trying
to
modify
this
yeah
because
it
seems
the
best
we're
gonna
get.
B
Jeremy
k,
can
you,
can
you
remind
us,
the
the
old
methods
still
work
correct
or
are
the
or
is
the
flag?
Does
it
throw
an
exception?
Now.
D
D
Yes,
that's
my
plan,
okay
and
I
I
plan
to
actually
remove
the
flag,
if
I
can
so
to
rub
it
in
even
further
okay
and
then
check,
because
I
need
to
check
because
again,
like
we
just
cast
this,
we
we
actually
have
a
couple
extra
flags
on
here,
but
then
we
cast
it
to
the
the
the
underlying
flags
that
go
to
are
are
defined
to
most
of
the
flags
in
there.
If
you
want
to
remove
it.
A
A
A
I
mean
it's
better
than
with
the
menu,
so
I
take
it.
I
mean,
I
think,
generally,
I
think
it's
fair
to
say
you
start
with
telling
people
not
to
use
it,
and
then
you,
basically
you
know,
you
know,
apply
more.
You
know
thumb
screws
I
mean
and
in
binary
formatter
we
said
we
start
with
making
a
throw
right
or
making
it.
You
know,
you
know
you
have
a
compat
flag,
that
you
have
to
turn
on
or
something
like
that
right,
and
that
would
be
the
same
here.
You
could
say.
A
D
C
D
A
D
D
A
Yeah,
maybe
we
should
consider
being
stronger
there
and
actually
tell
people
like
we
will
remove
it,
so
stop
using
this
and
then
the
other
thing
we
should
consider
is
given
that
you
add
the
apis
now
at
least
add
a
hyperlink
to
it
so
that
you
can
actually
point
people
to
like
if
you
rely
on
this
behavior.
Please
call
this
new
api,
so
you
can
put
that
guidance
somewhere
yeah.
A
Oh
never
mind
yeah,
sorry,
but
then
I
guess
my
yeah.
That
makes
it
a
little
bit
more
ugly
when
you
absolutely
if
you
remove
the
api
at
the
same
time
as
you
introduce
the
replacements
that
makes
it
a
bit
harder
for
people
to
migrate
right,
because
you
basically
ask
them
to
do
all
at
once,
but
then
in
six
they
just
get
a
compile
time
error
that
and
nothing
or
not,
even
that
you
guys
just
get
runtime.
A
D
A
A
B
A
Nice
all
right,
then
I'll
just
wait
for
the
freaking
window
to
actually
render.
A
Yep,
there's
literally
no
questions
on
youtube:
either:
okay,
fine!
So
then
let's
call
it
a
day,
and
then
I
see
you
guys
next
week.
I
guess.