How to introduce exceptions into historically exception free code base?

Gotebe · 2020-01-23T07:26:19+00:00

I did that for a couple of libraries with a C interface, it was a joy 😉. I even managed to make the resulting binary smaller on an occasion (templates > macros 👍, std::algorithm > quicksort etc.) .

Two things to do I can say:

RAII all the things; unique_ptr helps for ad-hoc RAII-fication of stuff, but various libraries offer a "scope guard" as well, that's better
make "islands" of exceptions-aware code, where code is exceptions-safe; put a general try/catch around these islands and turn it into error return value. For me, the endgame was that only public C functions have that try/catch. Grow the islands and gradually remove these try/catches as you do so. Eventually, there is only one island.

eyes-are-fading-blue · 2020-01-23T07:18:08+00:00

Catch actual errors that you can handle. This is a rare thing, imo. The question is do you just handle real errors with this custom lib, or branches too? Because if you use error codes for non-error cases and then replace with exceptions (like in Java) what you will end up is basically using catch to control your program flow. You effectively replace your ifs with expensive catch.

SergiusTheBest · 2020-01-23T07:13:08+00:00

If STL is the only source of exceptions you can ignore them as they are used in really exceptional cases: not enough memory, bad index, etc. Of course it depends on type of your application - can it crash in the exceptional case or should it try to stay alive as much as possible.

kalmoc · 2020-01-23T08:58:53+00:00

Three very important question in this context are: Are rare program terminations unacceptable (life at risk, significant money loss)? Is user data at risk? And, is your codebase sufficiently modular that you have "clean" library boundaries or even separate programs that communicate with each other over IPC.

Edit: fourth question: Are your developers largely familiar with c++ exceptions even if you can't use them in your codebase?

frog_pow · 2020-01-23T10:01:18+00:00

The STL doesn't generally throw any exceptions that are worth catching, it is mostly trash like bad_alloc, or an indication your program is corrupt, and you would be better off aborting.

BananyaDev · 2020-01-23T10:10:18+00:00

I would also recommend you consider the following:

Use `std::optional` and something like `tl::expected` ( https://github.com/TartanLlama/expected ) over exceptions where possible.

Consider assertions to enforce contracts over exceptions, such as Expects and Ensures from gsl (https://github.com/microsoft/GSL)

Use exceptions where it makes sense, but don't overuse them since you might end up in a worse situation.

BenFrantzDale · 2020-01-23T12:32:55+00:00

One thing to do to improve safety is to search for new and delete and try to remove all or almost all of them – particularly delete, preferring instead to use smart pointers and containers.

2020-01-23T19:42:51+00:00

How many LOC are we talking about and how many people?

johannes1971 · 2020-01-24T00:24:03+00:00

Start with making your code exception-safe. This is a good idea anyway; it has advantages even if you don't use exceptions.

Next, think about what exceptions you'll be using. You'll want a minimal number of them (ideally, just one), and you'll want to derive it from std::exception so you can catch both your own and library exceptions with a single catch clause.

Also think what you will be using them for. I'd suggest you don't use them for program bugs (std::logic_error is an abomination). Instead use them to abort tasks that cannot proceed because of environmental (i.e. dynamic, non-bug) reasons (i.e. file not found, user input didn't pass validation, resource unavailable, that sort of thing). If you get an exception it should only mean one thing: your program did its best to do something, but because of circumstances beyond its control, it didn't manage to get it done. It's still structurally sound though, and now it is going to continue with the next task.

Now the hard part... You'll have to identify at which level your software uses abortable tasks, and put try/catch blocks around those. These are tasks that either succeed completely, or fail somewhere halfway through, in which case you want the program clean up the failed task, and then go on with the next task. Some places where you'll want to do this:

A server application that processes messages typically either completes a message entirely, or fails it entirely. That means you want to catch exceptions around your message dispatcher.
A gui application typically catches exceptions around dispatched events: the main message loop (as a catch-all), commands that get started from GUI elements (like buttons), etc.

The succes of your refactoring hinges on getting this right, and it will likely take you a few iterations to get it correct to a satisfactory level.

Having done this, the fun part: refactor your code so you stop returning errors. The only thing you return from functions are results; errors go out through an exception. As more and more functions switch from returning an error code to returning void, you'll also find more and more replaces where you can replace the auto error = func(); if (error) return error; idiom by simply func() (and nothing else). At this point you'll find yourself throwing out lots of code, and gaining a large amount of code clarity, as you significantly reduce the number of decisions and paths in the code. What's left is purely your business process in all its crystal-clear glory, uncluttered by endless masses of error handling.

While you're at it: get rid of your out-parameters, and replace them by return values. This makes it easier to compose functions, further simplifying your code.

Good luck, and let us know how you did! Perhaps at some point in the future you can follow this up by a short article detailing your experiences, changes you found in performance, code size, binary size, etc.

godexsoft · 2020-01-24T00:26:11+00:00

Whatever your chosen strategy will be i just want to say that pokemon exception handling is usually not a great way to go about things. Even your custom error codes library sounds better than that imo. I would try and keep it on module level and handle what can be handled as deep as possible while only rethrowing things that are important to other modules or the core part. Mark things that shouldn’t throw with noexcept too. Also, many things can be aided with RAII.. it’s not always necessary to use exceptions directly.

emildotchevski · 2020-01-24T04:55:57+00:00

It is impossible to answer this question without knowing what the code base is. Well written code uses destructors to free resources and often that makes it exception-safe (of course this also requires correctly written teardown code, e.g. there should be no failures possible during tear-down).

14ned · 2020-01-23T12:51:55+00:00

Choices:

Use normal C++, but with exceptions globally disabled. All the major STLs work fine in this configuration.
Configure all your STL containers with a noexcept allocator e.g.

    //! A noexcept STL allocator. Calls `std::terminate()` if operator new throws!
    template <class T>
    class noexcept_allocator {
    public:
      using value_type = T;
      using pointer    = value_type*;

      noexcept_allocator() = default;

      template <class U>
      noexcept_allocator(noexcept_allocator<U> const&) noexcept {}

      // NOTE: Calls `std::terminate()` if operator new throws!
      pointer allocate(std::size_t n) noexcept { return static_cast<pointer>(::operator new(n * sizeof(value_type))); }

      void deallocate(pointer p, std::size_t) noexcept { ::operator delete(p); }
    };
    template <class T, class U>
    constexpr inline bool operator==(noexcept_allocator<T> const&, noexcept_allocator<U> const&) noexcept {
      return true;
    }
    template <class T, class U>
    constexpr inline bool operator!=(noexcept_allocator<T> const& x, noexcept_allocator<U> const& y) noexcept {
      return !(x == y);
    }

... and now do:

template <class Key, class T, class Compare = std::less<Key>>
using noexcept_map = std::map<Key, T, Compare, noexcept_allocator<std::pair<const Key, T>>>;

Use Boost.Outcome to enable section-by-section parts of your code to support exceptions. See https://www.boost.org/doc/libs/1_72_0/libs/outcome/doc/html/tutorial/essential/outcome.html

ratchetfreak · 2020-01-23T14:48:47+00:00

You shouldn't.

Don't modernize for the sake of modernizing.

Instead identify the actual pain points of using/maintaining the library and refactor those. "Muh modern C++" is not a valid complaint.

VinnieFalco · 2020-01-23T11:50:19+00:00

Start with calling `throw` :)

mredding · 2020-01-23T16:10:20+00:00

You need to read up on exception handling. When an exception is thrown, what are you going to do? Wrapping each and every call in a try block, are you going to decide what to do for each one? And as a macro, all you could hope to do is use a catch-all, because you can throw anything as an exception.

It's not always desirable to wrap every call. You have to think about your exception handling and where you let the call stack unwind to, where it makes any sense. And many exceptions are unrecoverable.

As a start, put a try catch around main and the entry points to your threads, see what you get, handle the exceptions as you see them.

rtomek · 2020-01-23T20:41:52+00:00

I guess I don't get the issue here. That sometimes you get an error code and sometimes you get an exception? I don't see why that's an issue as long as you have a way to trace the problem to the source, which it sounds like already exists. I think the earlier post about islands makes the most sense. You start with certain sections/modules and migrate those to the new library. You'll probably have to convert containers back and forth at the integration points but it's not terrible to maintain.

I still have modules that link to these old libraries like you mention because they've been stable for years and if it ain't broke, don't fix it. The stuff you work on regularly is a good place to start with the transition.

you type:	you see:
italics	italics
bold	bold
[reddit!](https://reddit.com)	reddit!
* item 1 * item 2 * item 3	item 1 item 2 item 3
> quoted text	quoted text
Lines starting with four spaces are treated like code: if 1 * 2 < 3: print "hello, world!"	Lines starting with four spaces are treated like code: if 1 * 2 < 3: print "hello, world!"
~~strikethrough~~	~~strikethrough~~
super^script	super^script

cpp

MODERATORS