[DGD] Fatal error when no user object returned

[bart at wotf.org]

When using a setup which separates connection and user objects properly, the
driver will not terminate on such things, unless your low level code fails to
handle errors in the next layer properly (and handling such errors is one of
the primary tasks of the kernel).

There really is a good reason for the conventional wisdom to use the kernel
library with dgd and build on top of that. Sure, you can write your own (I did
so more than once) and there is nothing wrong with that, but, it also means
you will become responsible for properly handling the low level interface with
dgd. 

When actually writing your own kernel, you'll find that dgd is picky, ie, it
doesn't tolerate the low level code not handling things properly in many
cases, and while this is annoying at first, it also means you are more or less
forced to implement things properly.

Not wanting to deal with all that? fair enough, use klib, cloudlib or an
unmodified gurbalib kernel or such :-)

At any rate, when you use proper layering of code in your lib, you can quite
make changes to your protocol handlers without causing dgd to terminate, even
if you cause an object to not compile.

Writing the low level code has many similarities to writing an operating
system, at least with regards to the approach you need.

Obviously, that doesn't entirely justify dgd terminating on this specific
error, I guess the only one who can explain the exact motivation for that
would be Felix. My point is that if it matters in the way you suggest (ie,
changing a http handler and causing dgd to terminate due to some mistake in
it), it is pointing at an improperly designed lib. Keep in mind that dgd is
not fluffos, and the direct interface with the driver requires a different
approach (as is also evident from the sefun discussion we had a while ago). 

As an aside, unless you use a properly designed and written kernel, there are
many more ways in which you can have dgd terminate or just hang. There are
various ways to deal with all those situations, and it involves choices. This
setup in general is what makes dgd much more flexible. (ie, if you dig deep
into gurbalib's kernel, you will see that it uses this to provide custom error
handling for a number of situations)

Bart.

On Thu, 7 Jun 2018 08:11:54 -0700, Dread Quixadhal wrote
> I think the main grumbling point here is that the idea of the driver 
> terminating if the connection object isn’t valid (either didn’t 
> compile, or didn’t have the right calling interface), made perfect 
> sense back when DGD was used as a game driver where everyone just 
> connected to it to play.  Not much of a game if nobody can connect, right?
> 
> However, now that it allows multiple ports, some or all of which can 
> be used for non-essential services, it’s not as convenient or 
> logical to have the whole thing shut down because one service 
> can’t operate.
> 
> The analogy would be an old school monolithic OS kernel, where 
> everything is compiled in, and an error in the network driver or 
> video driver would crash the entire system… or a modular kernel 
> where the same error would cause that module to die and be relaunched.
> 
> Of course, as long as we’re talking about DGD and not Hydra, the 
> source *IS* available, and thus one could modify it to have a 
> different behavior.  Who knows, if such changes were clean and 
> didn’t impact performance, they might even be accepted as a 
> compile-time option someday, in the mainline driver.  Only Dworkin 
> knows for sure. 😊
> 
> Sent from Mail for Windows 10
> 
> From: bart at wotf.org
> Sent: Thursday, June 7, 2018 7:53
> To: All about DGD and Hydra
> Subject: Re: [DGD] Fatal error when no user object returned
> 
> On Thu, 7 Jun 2018 16:05:40 +1000, Tony Demetriou wrote
> > Ideally an API would never crash.
> 
> It doesn't actually crash here either.
> 
> > 
> > If you violate the expected input, it should give an appropriate 
> > error message.
> 
> Which is exactly what it does.
> 
> The contention here is over this error being fatal, as in, DGD terminates.
> 
> As others argued, the call to fatal is a decision, its not ending up 
> there by accident, and hence calling it a 'crash' is actually not correct.
> 
> One can argue about it being proper for this to be a fatal error,
>  I've argued earlier I think it is and why I think it is appropriate,
>  but that is obviously a matter of opinion
> 
> However, comparing the low level interface provided by for example 
> DGD or any similar VM to the API provided by say the JRE, or klib or 
> any such object library is really not correct, they operate at 
> different levels, and serve different purposes. Integrating both 
> layers somewhat is obviously possible, look at current fluffos and 
> its ilk for an example of that, but it comes at a price both with 
> regards to complexity of the driver/vm and flexibility for the lpc 
> code it can run.
> 
> Bart.
> --
> https://www.bartsplace.net/
> https://wotf.org/
> https://www.flickr.com/photos/mrobjective/
> 
> ____________________________________________
> https://mail.dworkin.nl/mailman/listinfo/dgd
> 
> ____________________________________________
> https://mail.dworkin.nl/mailman/listinfo/dgd


--
https://www.bartsplace.net/
https://wotf.org/
https://www.flickr.com/photos/mrobjective/