Re: To go with Go or C/C++?
Paavo Helde <myfirstname@osa.pri.ee> writes:
?? Tiib <ootiib@hot.ee> wrote in
news:7f329313-3b6e-41f3-b644-d7b22980e60f@googlegroups.com:
In C code that I have seen the functions return an int. Sometimes
there is enum returned. One value (often 0) indicates success and rest
of the values mean error codes. It is unlikely that whole string
buffer and its size as parameters will be devoted to error handling in
real code.
And that's all the reason needed to avoid C-style error handling. If the
error infomration consists of a single integer, then at best you get
Oracle-style "Error ORA-34567" which you have to look up somewhere, or at
worst you get Microsoft-style "Operation could not be completed".
I honestly don't see why the app can't have an array of char *'s
itself, indexed by the "single integer", that can be printed
when the error is finally handled.
if ((fd = open(argv[1], O_RDONLY)) == -1) {
fprintf(stderr, "%s: Unable to open '%s': %s\n", argv[0], argv[1], strerror(errno));
return EXIT_FAILURE;
}
The 'array of char *s' can even be l10n or i18n as necessary (as in strerror(3)).
The use of errno here is an example, of course; an application can define
any set of error codes it likes for its error conditions and have the
equivalent of strerror(3) to generate an informative error message.
One might argue that this approach is superior to throwing descriptive strings
since the descriptive strings are littered all over the place instead of being
all in one place (potentially in an external text file for each locale) which
aids in l10n/i18n efforts.
scott