[DGD] Fatal error when no user object returned

[Blain]

I just see network connections as secondary to DGD's purpose.  If someone
is working on a user/socket object and messes it up temporarily, a random
user/metro connection trying to connect will suddenly kill the whole game
for no real outside.  Obviously, a lib can work around this, swapping out
for a dust object, etc.  Be mistakes Sy happen and I think an error for be
generated and connection closed without further effect.

On Tue, Jun 5, 2018, 18:10 Raymond Jennings <shentino at gmail.com> wrote:

> This is just my opinion, but if you violate the driver object's API
> you deserve to crash :P
>
> at least one case in the past, regarding missing functions in the
> driver object, receives similiar treatment.
>
> The reason then was that a missing function could have been due to the
> driver object's function table getting trashed.
>
> My guess is that from DGD's point of view, when a fundamental API in a
> core object such as the driver object is violated, it's more likely
> that it's because of a DGD bug.
>
> On Tue, Jun 5, 2018 at 2:26 AM, Blain <blain20 at gmail.com> wrote:
> > I don't see the purpose.  Not every port mentioned in the config file is
> > necessarily critical to MUD operation.  Sure, it's easy to do a
> workaround,
> > but I question the purpose of the explicit fatal shutdown.  A dust object
> > would need to be simple so as not to bug out of an interest or included
> > file happened to be unstable.  The sudden shutdown would lose any data
> > since the last data dump.  Keeping the game up and running and player
> data
> > intact are extremely important on a MUD.  I don't see this as a valid
> > excuse for losing data.
> >
> > On Tue, Jun 5, 2018, 01:34 Raymond Jennings <shentino at gmail.com> wrote:
> >
> >> In My Opinion (tm):
> >>
> >> Failing to return the proper type in a driver hook is a fundamental
> >> API violation.
> >>
> >> However, I think you can still just cause a runtime error and not return
> >> at all.
> >>
> >> Plus you could always have a burner object that just disconnects
> >> immediately when it's assigned a connection.  Not that hard.
> >>
> >> On Mon, Jun 4, 2018 at 11:26 PM, Blain <blain20 at gmail.com> wrote:
> >> > Instead of closing DGD when no user object is returned, would it be
> more
> >> > prudent to just close the incoming connection?
> >> > ____________________________________________
> >> > 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