I agree with the can't fail exception. If the function would
return a constant TS_SUCCESS and it is reasonable that
the user would expect that it would, then it could return
something other than the enum.
If it was me, I would permit exceptions for silly things like
checking the type/non-null of an argument, but I can understand
that some folks are not good with that.
john
On 12/09/10 10:04, Igor Galić wrote:
----- "Alan M. Carroll"<a...@network-geographics.com> wrote:
A point that came up in chat is the question of "can't fail" API
calls, which are those that current take no arguments. Examples would
be TSTrafficServerVersionGetMajor() or TSPluginDirGet(). Should we
have an exception for API calls that absolutely cannot fail?
I think I would support such an exception, for API calls that can't
fail and don't take arguments (the latter being, IMHO, a necessary but
not sufficien condition for the former).
Coming from the angle that a method call cannot possibly fail, we
need not return a status code, and we need not check for it either.
This means we can break up the API changes a bit more subtly.
TSReturnCode TSApiThatCantFailGet (POD *param);
now becomes
POD TSApiThatCantFail ();
likewise, we would drop the Set in setter methods that can't fail.
Basically what we're asking for is simple:
"Come back with the result, or not at all!" -- amc
As for the others, as Leif has already suggested, the standard form
TSReturnCode TSApiFoo (type in_param, type2 out_param, ..)
Additionally I would like to point out that if a method can fail,
it should do so as early and as hard as possible. i.e.:
TSReturnCode TSApiBar (type in_paramX, zomg_t in_paramY, type_3 out_param)
{
if (sdk_sanity_check_type(in_paramX) != TS_SUCCESS) {
return TS_ERROR;
}
....
return TS_SUCCESS;
}
So long,
i
