2020. december 17., csütörtök 14:36 keltezéssel, Rafael J. Wysocki <rafael@xxxxxxxxxx> írta: > [...] > > >> My thinking here that I shouldn't make assumptions for future platform > > >> implementations - there may be valid cases in the future where being > > >> able to return an error condition if there was an error would be useful. > > >> > > >> Just trying to keep this somewhat future proof. Returning an error > > >> condition seemed a useful thing to have available. > > > > > > You can still return an error while returning a platform_profile_option value. > > > > > > Just add a special value representing an error to that set. > > > > > I'd like to understand what is better about that approach than having an > > error and a returnable parameter? > > > > I'm probably missing something obvious but if I add an extra > > platform_profile option (e.g PLATFORM_PROFILE_ERROR) to be used in an > > error case (and return just an enum platform_profile_option) it seems I > > lose the granularity of being able to return a specific error condition. > > It doesn't feel like an improvement. > > And what's the user expected to do about the different error codes > that can be returned? Even assuming the users of the API cannot or will not handle different errors differently, who would benefit from getting rid of this information which may be an aid in debugging for those who know what they're looking at? And if a new enum value is introduced to signal an error condition, how is that going to be communicated to the users? A magic string like "error" or "-1"? Or under a single errno like -EIO? Personally, I believe neither of these two solutions are better than returning the actual errno which is deemed most appropriate by the platform profile handler. Or am I missing a third way? Regards, Barnabás Pőcze
