[DGD] Fatal error when no user object returned

[Blain]

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.