[DGD] Fatal error when no user object returned

[Raymond Jennings]

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