C++ producer-consumer using blocking buffer

Yup. Looks like a queue. Maybe all multithreading is really a queue? ... strokes beard philosophically

Naming:

• terminate() should probably be called finished() or done() or something similar. (To distance it from std::terminate). stop() would also be wrong, since that implies we're telling the threads to stop processing regardless of whether there's more input. What we're really saying is simply that there's no more input to process.
• next() should be called push()... because that's what it does.
• consume() would be better named something like wait_and_pop().

void terminate(){
    {
      std::unique_lock ul {m};
      if (stop || failed ) throw std::runtime_error("enqueing has stopped");
      stop = true;
    }
    cv.notify_one(); // notify stop signal
}

I don't think we need to throw an error if the queue is already stopped (or failed). We can just do nothing and return. (Similar to calling close on a file that's already closed. It's not wrong, there's just nothing to do). Especially since we have no way to check if the queue is currently stopped!

(It might be worth adding an bool is_stopped() const. Note that making this function const would mean making the mutex a mutable variable (which is fine)).

We should call notify_all instead of notify one. We presumably want all threads to stop waiting promptly.

We could use std::lock_guard instead of std::unique_lock (we don't need any of the extra functionality of std::unique_lock).

void next(T t) {
    {
    std::unique_lock ul{m};
    if ( stop || failed ) throw std::runtime_error ("enqueing has stopped");
    values.push(t);
    }
    cv.notify_one(); // notify the consumer (if waiting)
}

We could use std::move when pushing the value onto the queue: values.push(std::move(t));.

Again, we could use std::lock_guard instead of std::unique_lock.

std::optional<T> consume(){
    std::unique_lock ul{m};
    cv.wait(ul, [this]() { return !values.empty() || stop || failed; });
    if (values.empty()) { // if got notified and the queue is empty, then stop or failed have been sent
        if (stop)
            return std::nullopt;
        else
            std::rethrow_exception(_eptr);
    }
    // extract the value to consume
    T val = values.front();
    values.pop();
    return std::optional<T>(val);
}

Here we do need std::unique_lock. :)

Again we can do T val = std::move(values.front());

I'm not sure the logic here is quite correct. If the failed flag is set, we probably need to do something about it even if the queue isn't empty? (I don't know what your spec says though).

Destruction:

Yep, we need a destructor. It's quite possible for the Buffer to be destroyed while consumer threads are still trying to read from it. A contrived example:

auto consumers = std::vector<std::thread>();

{
    auto buf = Buffer<int>();

    for (auto i = 0; i != 5; ++i)
        consumers.emplace_back([&] () { while (true) { auto value = buf.consume(); if (!value) return; std::cout << value.value(); } });

    for (auto i = 0; i != 5000; ++i)
        buf.next(i);
    
    buf.terminate();

} // buf goes out of scope here! but we don't know that consumers have finished consuming!

for (auto& c : consumers)
    c.join();

We have two choices:

• Make this an obvious programming error (print an error message to std::cerr and call std::terminate if necessary (when failed isn't set, or when stop is set, but the queue isn't empty).
• Make it less dangerous (assume that input is finished and we want to finish processing it, so set stop in the destructor and then wait for the queue to be empty).

I think the second option is better - depending on whether threads have finished work as an error condition may end up calling std::terminate quite randomly.