On 02/11/2011 06:03 AM, Igor Galić wrote:
Right now, we have:
[snip]
~35 places where we'd need to change that.
39 if we count it like this: `` ack -l '(!|=)=\s*TS_ERROR' | wc -l ''
Might be worth the effort, I'm at least +0.5
Still doable.
Thinking about this a little more, and I'm still not entirely opposed to
#3 (it definitely has some merits), another concern is how people would
use this extra information. I mean, if the common pattern is still
if (TSSomeSDKApi(bufp, arg) != TS_SUCCESS) {
then we've added no value. In fact, we've probably made it worse, cause
now we would detect bad input / output parameters the same way as the
API not succeeding for other (good) reasons. The pattern plugins would
use to make this usable (and not worse) is something like
switch (TSSomeSDKApi(bufp, arg, &result)) {
case TS_SUCCESS:
// Do something good with the result., plugin specific
break;
case TS_NOT_FOUND: // (or something)
// We failed the operation, but not because of bad code or bad input.
// This could e.g. be by not finding something we looked for in
the req.
// Action here is plugin specific.
break;
case TS_ERROR;
// This might, or might not be a coding error, but the SDK could
not complete.
break;
case TS_BAD_INPUT:
case TS_BAD_OUTPUT:
// Probably assert or something, because this is a coding error and
// should be fixed, not dealt with at run time (IMO).
break;
default:
// Error cases that we're not aware of.
ink_release_assert(!"zOMG!");
}
So, looking at this, and thinking what an SDK developer would do in the
cases where they are using the APIs wrong, it sort of collapses down to
being very similar to option #1 anyways. The main difference is that a
plugin writer that wants to go out of his way and dealing with bad code
at run-time has an option to do so in #3. But I somehow doubt many
plugin developers would go through all these hoops on every SDK call?
-- Leif
