4 ms·

This may be true for checked exceptions, but certainly not for unchecked exceptions.

• mgaunard 4y ago
  All exceptions must be caught to satisfy lifetime invariants in multi-threaded contexts.
  • the_why_of_y 4y ago
    Of course. With unchecked exceptions, it's impossible to statically check that this is the case, so for system programming they are not an appropriate error handling mechanism.
    • mgaunard 4y ago
      None of system programming can be statically checked, since it's mostly about I/O with weak memory models.
      • Yoric 4y ago
        Caveat: we may be using different definitions of "system programming". The one I'm using is code that is fairly close to the system, i.e. will call into libc or into the kernel/libSystem/etc. as well as calling more-or-less directly into a bunch of system-specific .so/.dylib/.dll. In my experience as a system developer, you need to invest some time into understanding the invariants expected/promised by the libraries you're calling, but many of them map nicely to static types. Of course, if you're implementing e.g. a IPC or RPC layer, you need to deserialize (and validate along the way) your inputs, but there are very few systems that do not need to do that regardless.
        • mgaunard 4y ago
          Code that uses libc is just normal code.
          • Yoric 4y ago
            I don't disagree :)
    • josefx 4y ago
      > With unchecked exceptions, it's impossible to statically check that this is the case Aren't checked exceptions just a hint to the programmer? Also I don't see why static analyzers shouldn't be able to map out which functions throw which exceptions without having hints in the language itself, the information is in the code. Lastly if the goal is as simple as catch all exceptions, can't you just enforce a catch all on the top level?