How do i get rid of this warning?
Quote:Original post by Colin Jeanne
The code is part of a macro.
No, it isn't. It's simply part of the definition of the WspiapiLoad function, which is being defined inline in the header file.
Quote:Original post by iMalc
If it is unlikely to need to break out most of the time, then it is the perfect place to use an exception.
Unless it's a serious error happening - no, it's not.
Quote:Original post by Anonymous PosterQuote:Original post by iMalc
If it is unlikely to need to break out most of the time, then it is the perfect place to use an exception.
Unless it's a serious error happening - no, it's not.
Sure it is! It doesn't have to be serious, it just has to be an exceptional situation, something that wouldn't normally occur as I said.
Correct use of exceptions isn't limited to access violations. Even just a file not existing is plenty reason enough to use an exception.
I never said to use exceptions when it would need to throw most of the time.
Quote:Original post by iMalcQuote:Original post by Anonymous PosterQuote:Original post by iMalc
If it is unlikely to need to break out most of the time, then it is the perfect place to use an exception.
Unless it's a serious error happening - no, it's not.
Sure it is! It doesn't have to be serious, it just has to be an exceptional situation, something that wouldn't normally occur as I said.
Correct use of exceptions isn't limited to access violations. Even just a file not existing is plenty reason enough to use an exception.
I never said to use exceptions when it would need to throw most of the time.
For pratctical purposes, it's best not to throw for anything that might happen during a normal run of the program. And certainly not to break out of loops, ever.
Um... return statements, anyone? (If the code held in the macro is complicated enough to involve breaking out a for loop into surrounding context, then it probably should be its own inline function instead. We can just return from such a function; problem solved.)
Quote:Original post by ZahlmanYes that is definately my preferred solution too as I suggested earlier.
Um... return statements, anyone? (If the code held in the macro is complicated enough to involve breaking out a for loop into surrounding context, then it probably should be its own inline function instead. We can just return from such a function; problem solved.)
However I would caution the idea of making it inline.
Quote:Original post by Anonymous Poster
For pratctical purposes, it's best not to throw for anything that might happen during a normal run of the program. And certainly not to break out of loops, ever.
I disagree with the former (although I'm going to substitute "fairly typical" for the (IMHO) less well defined "normal"), although I'll agree with the later (for non erronus situations (*cough* what Zalhman says bellow your post *cough*), or situations that can't sanely, or shouldn't, be directly propigated further up the stack.
Quote:Original post by iMalcQuote:Original post by ZahlmanYes that is definately my preferred solution too as I suggested earlier.
Um... return statements, anyone? (If the code held in the macro is complicated enough to involve breaking out a for loop into surrounding context, then it probably should be its own inline function instead. We can just return from such a function; problem solved.)
However I would caution the idea of making it inline.
This is true :) I suggested marking as inline because that's closer to the original intent of using a macro in the first place (otherwise the person writing the library would have just made a *normal* function, assuming at least marginal competence). However, that decision may have been misguided in the first place, so :)
This topic is closed to new replies.
Advertisement
Popular Topics
Advertisement
