[DGD] Fatal error when no user object returned

[Raymond Jennings]

I was making an analogy to how if you do something batshit, the
implementation is not bound by any standards of reasonableness in how
it responds.

Failure to comply with DGD's api is analogous to that.  DGD's rules
for the driver object are very specific, and it's the duty of the LPC
programmer to comply with those rules.  Whether those rules are
reasonable or not is a different ballgame and unless you're prepared
to fork dgd yourself I don't think it's up for debate unless, as
dworkin said, you can meet the burden.

Any driver object that fails to comply with that api is, in essence,
provoking "undefined behavior" as it were and DGD is well within its
rights to crash.
On Fri, Jun 8, 2018 at 7:22 PM Blain <blain20 at gmail.com> wrote:
>
> What's "undefined" about any of this?
>
> On Fri, Jun 8, 2018, 20:59 Raymond Jennings <shentino at gmail.com> wrote:
>
> > I prefer to think of it as "failure to comply with DGD's api for
> > driver object function calls results in undefined behavior"
> > On Wed, Jun 6, 2018 at 9:29 PM Blain <blain20 at gmail.com> wrote:
> > >
> > > Calling fatal is a decision.
> > >
> > > On Wed, Jun 6, 2018, 23:16 Raymond Jennings <shentino at gmail.com> wrote:
> > >
> > > > Yes I have.
> > > >
> > > > A simple call to "fatal" with an error message, rather than explicit
> > > > code to decide what to do with the connection.
> > > >
> > > >
> > > > On Wed, Jun 6, 2018 at 8:59 PM, Blain <blain20 at gmail.com> wrote:
> > > > > If an object isn't returned, it goes out of its way to cause a fatal
> > > > > error.  Have you looked at the code?
> > > > >
> > > > > On Wed, Jun 6, 2018, 22:21 Raymond Jennings <shentino at gmail.com>
> > wrote:
> > > > >
> > > > >> On Wed, Jun 6, 2018 at 5:27 PM, Blain <blain20 at gmail.com> wrote:
> > > > >> > On Wed, Jun 6, 2018, 18:59 Raymond Jennings <shentino at gmail.com>
> > > > wrote:
> > > > >> >
> > > > >> >> On Wed, Jun 6, 2018 at 4:42 PM, Blain <blain20 at gmail.com> wrote:
> > > > >> >> > I, personally, only questioned if this was the wise way to
> > handle
> > > > null
> > > > >> >> > being returned.  I think it's an arbitrary decision by Felix
> > until
> > > > he
> > > > >> >> > states otherwise.
> > > > >> >>
> > > > >> >> That is your opinion, he has his, and since its his project what
> > he
> > > > says
> > > > >> >> goes.
> > > > >> >>
> > > > >> >> Arbitrary decisions are just as valid as well thought out ones.
> > > > >> >>
> > > > >> >
> > > > >> > That's what I said.
> > > > >> >
> > > > >> >> To me, a null response should just signal a rejection.
> > > > >> >> > It's not my code.  I'll deal.  But the lib I'm working on is
> > > > intended
> > > > >> to
> > > > >> >> be
> > > > >> >> > used by people who are, like me, not C/C++ programmers.  We can
> > > > handle
> > > > >> >> this
> > > > >> >> > issue. It's not hard. It list raises the complexity a bit,
> > > > >> >>
> > > > >> >> And doing it your way would increase the complexity of DGD by
> > adding
> > > > a
> > > > >> >> special case.  There is a tradeoff here, so I don't really think
> > it's
> > > > >> >> an arbitrary decision anyway.
> > > > >> >>
> > > > >> >
> > > > >> > No, it wouldn't.  DGD is currently explicitly giving a fatal
> > error and
> > > > >> > crashing. The other idea is to just close the connection.  I
> > don't see
> > > > >> > either as complex on DGD's side of things.  I don't see the LPC
> > side
> > > > >> being
> > > > >> > that complex either.  It's just a pitfall to be guarded against.
> > > > >> Something
> > > > >> > else to be aware of and take care to avoid.  I asked if crashing
> > on
> > > > >> purpose
> > > > >> > was the wise way to go and nobody has given reason for doing so.
> > The
> > > > >> > designer has apparently decided this was the way he wanted it to
> > be,
> > > > and
> > > > >> so
> > > > >> > it is.
> > > > >> >
> > > > >> > Besides, not making LPC handle it on its own would put policy
> > issues
> > > > >> >> inside DGD itself.  Presently, LPC is required to handle it by
> > > > >> >> returning an object, yet that object is allowed to behave
> > however it
> > > > >> >> wants to.
> > > > >> >>
> > > > >> >> > so I questioned
> > > > >> >> > if it has a be that way.  Using empty objects which
> > self-destruct
> > > > >> don't
> > > > >> >> > make sense, but it's certainly doable.
> > > > >> >> > I don't understand how you people
> > > > >> >> > think, hence the questioning.
> > > > >> >>
> > > > >> >> Most likely, we come from the point of view that LPC should bear
> > the
> > > > >> >> complexity burden as much as practically possible, and that
> > includes
> > > > >> >> keeping special cases out of DGD.
> > > > >> >>
> > > > >> >
> > > > >> > There is no special case being discussed.  DGD could go either
> > way.
> > > > >>
> > > > >> I probably should clarify.
> > > > >>
> > > > >> By special case I mean that presently, DGD doesn't need to worry
> > about
> > > > >> what to do if an object isn't returned.  It only has one case to
> > worry
> > > > >> about, "attach the connection to the object".
> > > > >> > ____________________________________________
> > > > >> > https://mail.dworkin.nl/mailman/listinfo/dgd
> > > > >> ____________________________________________
> > > > >> https://mail.dworkin.nl/mailman/listinfo/dgd
> > > > > ____________________________________________
> > > > > https://mail.dworkin.nl/mailman/listinfo/dgd
> > > > ____________________________________________
> > > > https://mail.dworkin.nl/mailman/listinfo/dgd
> > > ____________________________________________
> > > https://mail.dworkin.nl/mailman/listinfo/dgd
> > ____________________________________________
> > https://mail.dworkin.nl/mailman/listinfo/dgd
> ____________________________________________
> https://mail.dworkin.nl/mailman/listinfo/dgd