<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN"> <html> <head> <meta content="text/html;charset=ISO-8859-1" http-equiv="Content-Type"> </head> <body bgcolor="#ffffff" text="#000000"> Trever Fischer a écrit : <blockquote cite="mid:200902081202.28400.wm161@wm161.net" type="cite"> <pre wrap="">On Sunday 08 February 2009 04:54:53 am Richard Hughes wrote: </pre> <blockquote type="cite"> <pre wrap="">On Sun, 2009-02-08 at 02:15 -0500, Trever Fischer wrote: </pre> <blockquote type="cite"> <pre wrap="">According to a bug reported against KPackageKit (<a class="moz-txt-link-freetext" href="http://bugs.kde.org/show_bug.cgi?id=183565">http://bugs.kde.org/show_bug.cgi?id=183565</a>) a few days ago, PackageKit-qt can crash a program when packagekitd doesn't startup right. To be a bit more in- depth, it asks the daemon to make a new transaction, and starts tossing around a null transaction ID. The failure to start can be because of some invalid default backend, or just a regular segfault. </pre> </blockquote> <pre wrap="">Right, both of which are bad. </pre> <blockquote type="cite"> <pre wrap="">So, what would be the best way to handle this situation? Have the library return some error about it not starting? Have the daemon give a more specific error signal about why it couldn't start (if it can live that long)? </pre> </blockquote> <pre wrap="">Well, I think the daemon already does -- there's a limit what it can pass due to dbus-system activation limitations, but it should pass /something/. You then need to catch this error and throw an exception. </pre> <blockquote type="cite"> <pre wrap="">I think adding some method to the Client class to ping the daemon and see if it is up and making all the transaction-generating methods return NULL if it isn't up would be a good solution. </pre> </blockquote> <pre wrap="">You don't want to introduce startup latency in the GUI tools. </pre> <blockquote type="cite"> <pre wrap="">Another solution would be adding a check to see if daemon->GetTid() is null in ClientPrivate::createNewTransaction() and return NULL from there. Either way, the NULL eventually gets sent back up out of the library. </pre> </blockquote> <pre wrap="">Right, but what does NULL really mean? You need context. </pre> <blockquote type="cite"> <pre wrap="">Regular authentication error checking would catch it, but then we're using the same error condition for two totally different errors. </pre> </blockquote> <pre wrap="">Right, when you setup the transaction, make it clear the method can fail and that SomeError will be thrown. In the GLib library, in PkClient and PkControl, we return false and set the GError to a local domain, a DAEMON_CANNOT_START error code, and the geeky error in the message. </pre> </blockquote> <pre wrap="">Adding a 'getError' method of sorts to the Client class would be the Qt equivalent of this. Then, we can just return NULL for all the methods when something fails, and set getError to return a value like StartupError, PermissionError, or UnsupportedError. </pre> <blockquote type="cite"> <pre wrap="">I don't see a problem in making GUI applications catch setup errors, as even if you do GetUpdates when the daemon doesn't support it, it should also return an error and be handled in the the GUI rather than crash. </pre> </blockquote> <pre wrap="">I think handling both errors in the library takes the load off of the GUI developer of having to make sure the library won't crash. KPackageKit simply does this kind of code to check for an error: Transaction* t = Client::updateSystem(); if (t) { //Started! } else { //Didn't start. } </pre> <blockquote type="cite"> <pre wrap="">Richard. </pre> </blockquote> <pre wrap=""> </pre> <pre wrap=""> <hr size="4" width="90%"> _______________________________________________ PackageKit mailing list <a class="moz-txt-link-abbreviated" href="mailto:PackageKit@lists.freedesktop.org">PackageKit@lists.freedesktop.org</a> <a class="moz-txt-link-freetext" href="http://lists.freedesktop.org/mailman/listinfo/packagekit">http://lists.freedesktop.org/mailman/listinfo/packagekit</a> </pre> </blockquote> Hi Trever please check the git version of PackageKit-Qt, those errors should be handled more gracefully. Cheers Adrien </body> </html>