   Indicating no-throw best practices?
  Do you guys bother to put throw() after declarations of all functions you write that you know won't throw?  What about cases where you call external library or OS functions where you are not completely sure if they might throw?For example, usually it's recommended to not throw from dtors.  But, for example, I have cases where I'd call something like pthread_mutex_destroy() in a dtor, and then I am not sure whether I need to put try {} around that in case there is memory deallocation that might throw internally to the win32 pthreads library (though if I compile with /EHsc in VC++ I think only C++ exceptions are used, and the Win structured exceptions are ignored).So any recommendations about using throw() declarations?   
  Exception specifications will be abandoned (in C++0x? I think) so I wouldn't bother.   ;Quote:Original post by PruneDo you guys bother to put throw() after declarations of all functions you write that you know won't throw?  What about cases where you call external library or OS functions where you are not completely sure if they might throw?For example, usually it's recommended to not throw from dtors.  But, for example, I have cases where I'd call something like pthread_mutex_destroy() in a dtor, and then I am not sure whether I need to put try {} around that in case there is memory deallocation that might throw internally to the win32 pthreads library (though if I compile with /EHsc in VC++ I think only C++ exceptions are used, and the Win structured exceptions are ignored).So any recommendations about using throw() declarations?DON'T DO IT!It does not do what you think it does.  C++ exceptions are VERY different than those of Java and other languages.In C++ an throw declaration means "Catch everything that I didn't list, and if this would throw an exception treat it as a fatal error, immediately terminate the program with no cleanup."  There are very few times when it gives an optimization benefit, and is almost always the wrong thing to do.There are very few reasons to throw exceptions in C++.  You can write perfectly valid C++ code that NEVER throws.  The standard library has options to disable or avoid throwing exceptions on basically everything, and the few things that don't can be checked by yourself beforehand.If you use libraries that throw exceptions, obviously you need to catch those.  But it is much better if you write your code defensively, and never allow for the exceptional cases to exist in the first place.   ;  Or, write your own exception code.   ;Quote:Original post by frobIf you use libraries that throw exceptions, obviously you need to catch those.  But it is much better if you write your code defensively, and never allow for the exceptional cases to exist in the first place.This is a very unexpected statement from you. How often do you have control over the existence of exceptional cases? Arent they usually things out of your control, such as out of memory, file not found...   ;Quote:There are very few reasons to throw exceptions in C++.Exceptions are the best examples of the principle of separation of concerns in C++, so I can't imagine giving it up as a basic design paradigm.  I have seen enough written on the subject, and from my own experience, to be convinced that it makes for better software engineering.  It's not perfect, but better than without.  What I'm interested in is making the best of what's provided by the language in that respect.   ;  @Prune - traditionally they've been avoided in console games as enabling exceptions greatly increases the size of your executables, which is very, very bad. Most failure cases can be covered with "error"/"invalid" return values.Quote:Original post by iMalc How often do you have control over the existence of exceptional cases? Arent they usually things out of your control, such as out of memory, file not found...Well in a console game we would traditionally just let it crash in those circumstances, and QA-the-fuck-out-of-it before shipping to ensure they don't happen.For out-of-memory, you should allocate enough in advance, only ever exceeding that amount for "fluff" (e.g. particles) which can fail gracefully if an allocation fails.For file-not-found, you can usually fail gracefully as well, without throwing an exception. e.g. If a texture isn't found, we usually return a stupidly bright coloured texture so that QA notices the failure.   ;Quote:Original post by PruneQuote:There are very few reasons to throw exceptions in C++.Exceptions are the best examples of the principle of separation of concerns in C++, so I can't imagine giving it up as a basic design paradigm.  I have seen enough written on the subject, and from my own experience, to be convinced that it makes for better software engineering.  It's not perfect, but better than without.  What I'm interested in is making the best of what's provided by the language in that respect.Exceptions should only be used in exceptional circumstances.Memory allocation failure is an exceptional case:  what are you gonna do about it?  It will happen at a lower level than your code, it should be handled gracefully by a higher level than your code.  Your code need never concern itself with memory allocation failure.  That's what exceptions are for.Not finding a file is more of an expected case: you should handle it locally, and if that is really really not possible, raise an exception and let some one else worry about it.Consoles and other programs get by without using exceptions, but they generally do not follow good engineering practice.  You will find they make themselves smaller by just not handling error conditions at all.  The old "I only do half what you do, but in half the space!" paradigm.  The throw() spec in C++ is broken and should not be used.  C++ is not Java.  Java exceptions are just like status return values in C except they allow rooted object heirarchies and RTTI to be used as part of handling the return values.   ;  There are lots of reasons to throw (and catch) exceptions in C++.There are basically no reasons to write exception specifiers (i.e. 'throw()').   ;Quote:Original post by Narf the MouseOr, write your own exception code.How do you mean? Throwing your own exception-class or doing something like:if (error){    some_global.add_error("error occurred");    return null_value;}