[DGD] Fatal error when no user object returned

[Raymond Jennings]

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