5 ms·

My dream exception-related feature would be compile-time verification of noexcept. I don't care what gets thrown, because it's in the end going to be an std::e

by blub 10y ago

My dream exception-related feature would be compile-time verification of noexcept. I don't care what gets thrown, because it's in the end going to be an std::exception (this is the part that Java messed up) I do care if a function will throw, because it radically changes its behavior. The problem I want to avoid is a silly function such as stoi throwing and having the exception propagated up to main, after which the whole program (orderly) shuts down. Right now this can be avoided only with careful exception design and making sure all exception "escape points" to C functions, message loops, etc are covered. Swift I think is one of the few languages supporting this.

youdounderstand 10y ago
Good luck when your program is dynamically linked to a library built with a different version of STL.
- brandmeyer 10y ago
  Wouldn't this run afoul of the ODR, anyway?
  - blub 10y ago
    I don't think so, ODR applies per program, the library and main program are separate. Object layouts will be likely different and the main program will probably crash.
    - brandmeyer 10y ago
      Not so: The Standard doesn't have anything to say about the differences between static and dynamic libraries, or the differences between a .exe and its .dll's (or .so's). The program is composed of all the things that link into it as far as the ODR is concerned. The breakage from mixing different library versions (say, MSVCRT versions, for example) is a direct result of violating the ODR.
      - blub 10y ago
        The standard doesn't say anything at all about dynamic linking AFAIK, so it's basically OS-dependent. I think it works (as in the algorithm is well defined) in Linux, but it's best avoided due to complexity and non-portability.
- blub 10y ago
  Exceptions or STL classes shouldn't cross library boundaries though, otherwise things will break.
  - user5994461 10y ago
    And that's why exceptions have no real world usage in C++, except for a few local functions here and there.
  - gpderetta 10y ago
    It will work perfectly fine as long as the libraries use compatible ABIs. Make sure that your compiler provides a stable std library ABI.
    - blub 10y ago
      Good point that it's technically doable. Is this done a lot in practice? I had the impression that a lot of projects stick to C APIs in dynamic libraries.
      - gpderetta 10y ago
        MSVC does not guarantee a stable standard library ABI, so those that need to target it are out of luck. In linux land, the switch from libstdc++5 to 6 still haunt the memories of many, although it was quite a long time ago (gcc 3.4) and the ABI has been stable since. In practice the reason that many projects provide a C ABI is that they want to interoperate with other languages and the C ABI, being extremely minimalist, is the least common denominator.
saurik 10y ago
> I don't care what gets thrown, because it's in the end going to be an std::exception (this is the part that Java messed up) I don't understand: std::exception is entirely optional (and I, for example, never use it: I always build my own exception hierarchy; but, even though I write my native code almost exclusively in C++, I believe it is absolutely incorrect to expose a C++ API from a library, so you'd never know or care) while in Java you absolutely have to implement Throwable and Exception is actually designed well enough that most people (not me, of course ;P) generally use it... I mean, in C++ you literally can just throw a "const char *" and catch that.
- blub 10y ago
  By Java mess I meant exception specifications (throws/doesn't throw vs. exception names), sorry for the confusion. The important thing with exceptions in C++ is having a root class. I use std::exceptions, others are also ok as long as they are used consistently. If the goal is to trap everything, like in a library even ... is ok. The big difficulty lies in isolating certain kinds of exceptions to components. Some are recoverable, others should lead to termination, some should interrupt the current operation, others should trigger a retry. The type system offers no support with that. Verification of noexcept would be a start, as it allows some rudimentary marking of boundaries.
- jasonzemos 10y ago
  I happen to believe the inverse of all of this. Yes std::exception is optional, but why not use it to root your hierarchy? The only time I've answered in the negative is when the project specifically required no standard library could be used (yes, great that it's optional!). I sympathize with C-compatible API's to simplify an interface, though it's not my first choice. Rooting hierarchies in std::exception integrates library code safely and consistently -- especially over time and code revision to both the library and your end -- because at some point after specific exceptions are all missed some `catch(std::exception)` is hit on errors from both you and the library, and a consistent `what()` call can eventually inform the user with a message.
  - saurik 10y ago

by blub 10y ago

youdounderstand 10y ago

Good luck when your program is dynamically linked to a library built with a different version of STL.

brandmeyer 10y ago
Wouldn't this run afoul of the ODR, anyway?
- blub 10y ago
  I don't think so, ODR applies per program, the library and main program are separate. Object layouts will be likely different and the main program will probably crash.
  - brandmeyer 10y ago
    Not so: The Standard doesn't have anything to say about the differences between static and dynamic libraries, or the differences between a .exe and its .dll's (or .so's). The program is composed of all the things that link into it as far as the ODR is concerned. The breakage from mixing different library versions (say, MSVCRT versions, for example) is a direct result of violating the ODR.
    - blub 10y ago
      The standard doesn't say anything at all about dynamic linking AFAIK, so it's basically OS-dependent. I think it works (as in the algorithm is well defined) in Linux, but it's best avoided due to complexity and non-portability.
blub 10y ago
Exceptions or STL classes shouldn't cross library boundaries though, otherwise things will break.
- user5994461 10y ago
  And that's why exceptions have no real world usage in C++, except for a few local functions here and there.
- gpderetta 10y ago
  It will work perfectly fine as long as the libraries use compatible ABIs. Make sure that your compiler provides a stable std library ABI.
  - blub 10y ago
    Good point that it's technically doable. Is this done a lot in practice? I had the impression that a lot of projects stick to C APIs in dynamic libraries.
    - gpderetta 10y ago
      MSVC does not guarantee a stable standard library ABI, so those that need to target it are out of luck. In linux land, the switch from libstdc++5 to 6 still haunt the memories of many, although it was quite a long time ago (gcc 3.4) and the ABI has been stable since. In practice the reason that many projects provide a C ABI is that they want to interoperate with other languages and the C ABI, being extremely minimalist, is the least common denominator.

saurik 10y ago

> I don't care what gets thrown, because it's in the end going to be an std::exception (this is the part that Java messed up) I don't understand: std::exception is entirely optional (and I, for example, never use it: I always build my own exception hierarchy; but, even though I write my native code almost exclusively in C++, I believe it is absolutely incorrect to expose a C++ API from a library, so you'd never know or care) while in Java you absolutely have to implement Throwable and Exception is actually designed well enough that most people (not me, of course ;P) generally use it... I mean, in C++ you literally can just throw a "const char *" and catch that.

blub 10y ago
By Java mess I meant exception specifications (throws/doesn't throw vs. exception names), sorry for the confusion. The important thing with exceptions in C++ is having a root class. I use std::exceptions, others are also ok as long as they are used consistently. If the goal is to trap everything, like in a library even ... is ok. The big difficulty lies in isolating certain kinds of exceptions to components. Some are recoverable, others should lead to termination, some should interrupt the current operation, others should trigger a retry. The type system offers no support with that. Verification of noexcept would be a start, as it allows some rudimentary marking of boundaries.
jasonzemos 10y ago
I happen to believe the inverse of all of this. Yes std::exception is optional, but why not use it to root your hierarchy? The only time I've answered in the negative is when the project specifically required no standard library could be used (yes, great that it's optional!). I sympathize with C-compatible API's to simplify an interface, though it's not my first choice. Rooting hierarchies in std::exception integrates library code safely and consistently -- especially over time and code revision to both the library and your end -- because at some point after specific exceptions are all missed some `catch(std::exception)` is hit on errors from both you and the library, and a consistent `what()` call can eventually inform the user with a message.
- saurik 10y ago