Version: (using KDE 4.0.0) Installed from: SuSE RPMs Some checks for return codes are missing. Examples: Would you like to add more error handling for return values from "fseek" and "fread" like in the function "TeXFontDefinition::read_VF_index"? http://websvn.kde.org/trunk/KDE/kdegraphics/okular/generators/dvi/vf.cpp?revision=695802&view=markup
Patches welcome :-)
Which exceptions should be thrown if the mentioned function calls will fail?
I think you miss the point other people told you already: KDE generally do *NOT* use exceptions. And so Okular.
I hoped that exception support will be improved with KDE 4.x. Are there any other error handlers that should be notified about software failures? Do you expect to change the function "read_VF_index" to return an error code?
By the way: I wonder a bit about the following source code. macrotable = new macro[max_num_of_chars_in_font]; if (macrotable == 0) { kError(kvs::dvi) << i18n("Could not allocate memory for a macro table.") << endl; exit(0); } I was informed that the program might be terminated by the new operator in the ENOMEM case if exceptions were switched off. I assume that there is no need to check for the null pointer then. Otherwise, I would prefer the reaction "exit(errno)" instead of the current "exit(EXIT_SUCCESS)".
If the exceptions are switched off, that "exit(0);" is not even reached. Thus, no need to worry. > Do you expect to change the function "read_VF_index" to return an error code? Didn't you offered yourself for writing a patch? ;)
> If the exceptions are switched off, that "exit(0);" is not even reached. Thus, no need to worry. Thanks for this clarification. I suggest to delete dead code in this case. Is a preprocessor symbol defined by the CMake infrastructure that specifies if a null pointer check will be required for failed new calls? > Didn't you offered yourself for writing a patch? ;) I try to achieve consensus on such API changes before I would fiddle with source code. Will the "errno" value range be reused for return codes? Can I read more about the expected error handling at "http://api.kde.org/"?
Hi, this type of technical discussion should be done on various mailing lists where developers can elaborate and choose how to manage this development hints. Thanks for your suggestions! Regards.