Re: To go with Go or C/C++?
scott@slp53.sl.home (Scott Lurndal) wrote in
news:7Awit.2563$8u7.1014@fed10.iad:
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)).
Sorry, I think I missed your point. It seems like you advocated using
fixed error description strings, but then went on and composed a dynamic
error message containing multiple variable parts, like the actual file
name. This is exactly the kind of error message I was talking about (only
it should be thrown as a part of a C++ exception so that it can be
catched higher above and reported appropriately (dumping to stderr is
rarely the right thing to do, and low-level code containing things like
open() would not have any idea about that anyway)).
Cheers
Paavo