[DGD] Fatal error when no user object returned

[Blain]

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