On Sat, 16 Jan 2010 17:54:36 -0800 Colin McCabe <cmccabe@xxxxxxxxxxxxxx> wrote: > On Sat, Jan 16, 2010 at 3:21 PM, Pete Zaitcev <zaitcev@xxxxxxxxxx> wrote: > >> Shouldn't ncld_unlock and ncld_close return an error code rather than > >> just eating all errors? The server certainly does sometimes send back > >> error responses for these requests. > > > > This is an old bone of contention. The problem is, suppose the > > application is cleaning up for exit. What is it supposed to do with > > the error code? It cannot even retry sanely. > > If it's important enough for you to print out an error (*not* debug) > message in the library, it should be important enough to pass along to > the library user. > > After all, not everyone might be using a command-line app. Some people > might want to see the error reflected in a dialog box, etc. I'm going to try and explain again why the tear-down calls must not return operation errors (they are free to return programmatic errors). This is an important point for API design. Suppose for a moment that ncld_end_sess returns an error. What is your application going to do about it? You seem to be suggesting to pop a dialog. But what is in the dialog for the user? What can a user do? The answer is: a) retry, b) resign to the loss of data and terminate the application forcefuly in the OS. Or, actually, first (a) and then (b). And for the (b) to work above OS you'll have a forceful tead-down method anyway (or rely on OS). What's more, some applications do not have a way to interact with a human (e.g. tabled). And this is where you got the logics completely wrong. When I pointed that requirements of such applications dictate a call that unconditionally ends the life of a structure or handle, you (correctly) pointed out that interactive applications exist too. But what of it?! The API must satisfy both kinds! The correct approach -- and only if you _really_ have no alternative to have some data outstanding or have other server interaction on close -- is to provide a separate "flush" method, which can fail. Then, the retry dialogs or other methods (e.g. copying of data into other handle) can be used sanely. -- Pete P.S. ncld does not have a flush method because its writes are synchronous. And if we cannot contact a server to close a session, it does not matter. So the whole discussion is moot really. Nonetheless I think it's important to have it, in general sense. -- To unsubscribe from this list: send the line "unsubscribe hail-devel" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
