3 ms·

Exception specifications (deprecated) aren't the same as checked exceptions, which I think was what some people might have in mind. In theory, they look like t

by uxcn 11y ago

Exception specifications (deprecated) aren't the same as checked exceptions, which I think was what some people might have in mind. In theory, they look like they solve a number of problems, but in practice they really create more than they solve. Even Java language designers have said that checked exceptions were a mistake. The noexcept keyword was actually added to address some of the limitations.

Noughmad 11y ago
I agree that these things get ugly very quickly. Another thing is that you aren't always catching all exceptions; for example, sometimes you are sure that something is in bounds, but the function is still declared as throws(out_of_range) or similar. Is there a better way to do it, maybe a static analyzer or IDE warning about possible exceptions?
- uxcn 11y ago
  Instead of exceptions, I personally prefer using assertions to verify things like preconditions; in which case if an assertion fails the software should generally crash before getting into a worse state. Arguably, if the software shouldn't crash it's probably not an exception. Assertions can also give an analyzer a set of preconditions to check. For example, Clang's static analyzer parses assert statements [1]. I'm not sure it uses them to verify the preconditions, but regardless it's still a good way to express them. Another way to express constraints are attributes, which static analyzers (and optimizers) also use. For example, GCC has a number of function attributes [2] to express invariants about code. [1] http://clang-analyzer.llvm.org/scan-build.html#recommended_debug http://clang-analyzer.llvm.org/scan-build.html#recommended_d... [2] https://gcc.gnu.org/onlinedocs/gcc/Common-Function-Attributes.html#Common-Function-Attributes https://gcc.gnu.org/onlinedocs/gcc/Common-Function-Attribute...

3 ms·

Exception specifications (deprecated) aren't the same as checked exceptions, which I think was what some people might have in mind. In theory, they look like t

by uxcn 11y ago

Noughmad 11y ago
I agree that these things get ugly very quickly. Another thing is that you aren't always catching all exceptions; for example, sometimes you are sure that something is in bounds, but the function is still declared as throws(out_of_range) or similar. Is there a better way to do it, maybe a static analyzer or IDE warning about possible exceptions?
- uxcn 11y ago
  Instead of exceptions, I personally prefer using assertions to verify things like preconditions; in which case if an assertion fails the software should generally crash before getting into a worse state. Arguably, if the software shouldn't crash it's probably not an exception. Assertions can also give an analyzer a set of preconditions to check. For example, Clang's static analyzer parses assert statements [1]. I'm not sure it uses them to verify the preconditions, but regardless it's still a good way to express them. Another way to express constraints are attributes, which static analyzers (and optimizers) also use. For example, GCC has a number of function attributes [2] to express invariants about code. [1] http://clang-analyzer.llvm.org/scan-build.html#recommended_debug http://clang-analyzer.llvm.org/scan-build.html#recommended_d... [2] https://gcc.gnu.org/onlinedocs/gcc/Common-Function-Attributes.html#Common-Function-Attributes https://gcc.gnu.org/onlinedocs/gcc/Common-Function-Attribute...