Exceptions are ideal for happy path programming. You keep state in the stack and build your software so things get thrown away. For some types of programming this is not that important but for OLTP it is very handy.
Basically this approach is handle errors if you know what to do with them, otherwise leave the error for something else.
In erlang, where you have one process per transaction, and nothing handles the error, the process crashes.
In C++, you could just have an exception handler around a transaction, and then when an exception reaches that point you throw away the transaction, but log that it failed, you could have exception handlers below this to try and do rollbacks etc.
This is overly simplified but it gives a basic idea.
In my experience, the amount of interesting logic that "something else" does is vanishingly small. An arbitrary real-world example probably just logs or returns a string that is opaque and mostly useless to any potential error recovery mechanism.
In theory one could throw a FileExistsException with semantic and accessible data like filePath, but as things get this specific, they practically become part of the API. And a leaky part at that. The top-level entities that need to handle the exception need to know, somehow, that (1) encapsulated implementation details may throw something specific and (2) what to do with the thrown events.
So, practically, programs tend to catch std::exception, and pass the opaque error string on to some form of external I/O system (logs) with some minimally informative error status code (ERROR, 5XX, -1, false, null).
It is interesting to perform transaction failure operations, but there is no std::transaction_aborted, std::connection_dropped, or std::resource_busy. More realistically, std::exception is caught, which could just as easily be std::bad_alloc or std::domain_error. What do you do with a domain_error? I don't know either.
At any rate, the most interesting feature for transactional logic is RAII semantics, and you don't need to use exceptions to leverage those.
OLTP in this context is indeed online transaction processing.
This general approach of «let it "crash"[1]» or happy path programming is what I used when I wrote OTLP systems for mobile networks which were performing financial transactions. The exception handling would allow you to write fairly complex business logic and relying on exception handling to recover to a stable state.
[1]: Crashing in Erlang terms is not at all what people generally mean with crashing. It is a very unfortunate word because in part many of the problems in node.js comes from joyent not understanding what "let it crash" meant - it did not mean let the unix process crash. Erlang does one process per transaction and they are incredibly lightweight. Some details from joyent can be found here: https://www.joyent.com/node-js/production/design/errors
https://ninenines.eu/articles/dont-let-it-crash/
Basically this approach is handle errors if you know what to do with them, otherwise leave the error for something else.
In erlang, where you have one process per transaction, and nothing handles the error, the process crashes.
In C++, you could just have an exception handler around a transaction, and then when an exception reaches that point you throw away the transaction, but log that it failed, you could have exception handlers below this to try and do rollbacks etc.
This is overly simplified but it gives a basic idea.