Emily Shaffer <nasamuffin@xxxxxxxxxx> writes: > Is there a reason not to use this kind of struct and provide > library-specific error code enums, though, I wonder? You're right that > parsing the error string is really bad for the caller, for anything > besides just logging it. But it seems somewhat reasonable to expect > that any call from config library returning an integer error code is > referring to enum config_errors... In addition to what Peff already said, I think the harder part of it is to parametralize the errors in a machine readable way. A part of a library may say (with an enum) that it is returning "Ref cannot be read" error, with a parameter that says "The ref that caused this error was 'refs/heads/next'" which makes "Ref cannot be read" error has one parameter. "Ref cannot be renamed" may have two (old and new name). Other errors from some library functions may not even be of type "string". Coming up with the enums to cover the error conditions (which Peff covered well) is already a lot of work. Making sure each of them take sufficient parameters to describe the error usefully adds more on top. And the code to pass these variable number of parameters of variable types would be, eh, fun---it would be error prone without compiler help.
