Re: To go with Go or C/C++?
Scott Lurndal wrote:
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.
It is simple and the technique is frequently used in C. The downside is
the decision on what to do with the data is locked into the code at the
point of generation. If the same information is included in an
exception object, who ever catches the exception can chose how to use
the information. This is especially useful when the error is generated
from within a library: the application should decide how to report
errors, not the library.
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.
Which is why throwing an object that contains the information used to
generate the string is a superior approach. You can apply the same
internationalisation at a higher level. Not throwing a string also
reduces the risk of cyclic out of memory exceptions.
--
Ian Collins