[reactordev]

Which is like making cookies without butter. It can be done, but why would you want to? The standard library exists for this reason. To provide these abstractions. And I laugh at the idea that C++ could ever be exception free.

[jandrewrogers]

I am always baffled by the assertion that C++ cannot be exception-free. The vast majority of C++ code bases I have worked on, at companies large and small, have been exception-free. It is completely ordinary to have no exceptions, and is largely the de facto reality for a lot of C++ development.

In some vanilla app code exceptions are fine, but they introduce nasty edge cases in the kinds of systems code architectures C++ is mostly used for these days. Additionally, they don’t solve an urgent problem in practice that would strongly incentive someone to use them, so it the price of admission is rather steep for minimal benefit.

[pjmlp]

It isn't compliant with ISO C++ standard library for starters.

I really wish that everyone that plagues C++ library fragmentation with disabled this, disabled that, just stick to C and leave C++ community alone, so that we can fully enjoy the language as designed.

[verall]

I really disagree with this, C++ is a "choose your own adventure" language, I think this is it's main strength. You decide _everything_, which is conducive to writing systems software at many different levels - 1 language that you can reasonably write HLS+FW+KMD+UMD+libs+CLI+GUI with good support in all cases.

[snovv_crash]

The toolchain and OS I primarily target at my current job doesn't support exceptions. I can stil benefit from all the other aspects of C++ though.

[jjgreen]

It would make the world a better place if your wish were to come true, even better with <language A> and <language B> replacing C/C++

[pjmlp]

For me that would be C#, as it is the closest to Modula-3 ideas in mainstream computing, but I doubt many would agree, specially die hard C and C++ devs in some sub-communities, where knowing by heart Assembly opcodes is a reason to be proud of.

I guess we need something else everyone can agree upon.

Until then, the computing foundations will kept be being written in C++, until some big name decides to rewrite LLVM, GCC and VC++ into something else.

[formerly_proven]

C++ was designed?

[pjmlp]

Yes, as much weird as it may sound to those bashing it.

[CamperBob2]

In the sense that the Chernobyl reactor, the Boeing MCAS system, and the duck-billed platypus were designed, yes.

[reactordev]

You can’t guarantee the underlying memory so you can’t guarantee your app won’t blow up. You can handle errors, or expects, or however you want to call “exceptions” without the stdlib but you still have error states, you still have deterministic code branches, you may not have RTTI and non-deterministic std::exception but you still have the concept of an exception. The alternative is to segfault.

[jandrewrogers]

You are correct that there is code that solves a similar class of problems as exceptions. This code exists because it is can gracefully handle cases that exceptions handle poorly, in addition to the cases exceptions handle well. The literal C++ exceptions are an inferior tool.

It is trivial to “guarantee” the underlying memory and is idiomatic for a lot of software that cares about performance or reliability. That is code anyone can write if they care. There isn’t much that can go wrong with memory allocation if you are not allocating memory from the system. No one is requiring C++ developers to poorly duct tape a bunch of rubbish STL together and call it an app. That simply isn’t something you see much in the hardcore systems domains where C++ is the tool of choice.

Somehow, mission-critical software is routinely written in C++ without exceptions and it works just fine. Error states are a normal part of all code, no exceptions required since obviously many languages don’t have them. And no, the alternative is not a segfault. C++ is designed to work just fine without exceptions. The language allows you to bring your own error/exception handling models with minimal overhead, same way you can import alternative ownership/safety models.

[reactordev]

“Error states are a normal part of all code, no exceptions required since obviously many languages don’t have them.”

An error and an exception are the same concept. Yes, it’s true that not using the std::exception class or any template named “exception” is exception free code. But you’re just lying to yourself. An error check or an assert or verify not <condition> is a “catch”.

[thegrim33]

No, they're not the same concept, they're both ways to express error conditions but they way they function are very different. People very intentionally do not use exceptions because of how they function and the potential impact on performance compared to other ways of error handling. As well as having other negatives, which other people below have listed when you made a similar comment.

[pagghiu]

You can definitively use C++ in exception free way. I've been working on multiple Exception free codebases for work.

One large open source project that is using Exception free C++ is SerenityOS for example https://github.com/SerenityOS/serenity

The best way to write proper exception free C++ is not to use the C++ Standard Library.

[reactordev]

No, instead of using std::exception, serenity has ErrorOr template. C’mon, that’s basically the same thing. Whatever you want to call it, ErrorOr, OptionalWithError, Exception, you have branching code paths that deal with null/undefined conditions vs your known happy path. Exceptions / Error Handling / it’s all the same class of crap.

Only in C++ land do developers delusion themselves into thinking their way isn’t this way. That exception free means just simply not doing try/catch. jandrewrogers made a good argument below about memory safety and allocations in regards to mission-critical code but even in that scenario, underlying memory can be manipulated by MITM or other conditions that could cause corruption or segfaults in allocator pages.

[pagghiu]

> No, instead of using std::exception, serenity has ErrorOr template. C’mon, that’s basically the same thing.

I think that handling errors with ErrorOr<T,E> or similar techniques (I use something similar too) is very different from exception handling.

My main problems with exception handling are:

1. It's not zero-overhead (brings in RTTI often) 2. You can't know if a function throws something by looking at its signature 3. You don't know what types exceptions a function can throw 4. It doesn't force users to handle errors that can happen, leading tomore "happy path" style code

Something like ErrorOr or similar with [[nodiscard]] ticks all the above 4 points.

[reactordev]

If the argument is purely don’t use std::exception if you don’t want the overhead, use MyExceptionTemplate because it doesn’t introduce overhead then sure, I’m for that. If the argument is don’t use it because it’s non-deterministic, use MyErrorWrapperMagic, fine. But in the software engineering sense you are still exception handling, only deterministically - which I like. Everyone is getting hung up on semantics of std::exception instead of exceptions. Exceptions are a part of everyday coding. Why we call things exception-free when we really mean “goto-free”. I’m not a fan of goto jumps in my code.

ErrorOr is a better design for things to be deterministic. The point I was trying to make is that exceptions are errors and error handling and exception handling (while implemented differently) are essentially the same thing. In C++ std::exception is “exceptions” and everything else is “pretty error”. It doesn’t matter how the house is decorated. Exceptions = Errors = Oopsies = NotIntendedState

[jpc0]

> C’mon, that’s basically the same thing

I'm not going to talk about errorOr specifically because I don't know how it's implemented but rather your premise.

Exceptions are the modern goto, the try catch may be in the caller function. Or it could be 3 inherented classes away (this is hyperbole, I'm not sure if it would actually work) with so much indirection it would be impossible to follow the code flow other than to step in a debugger. So in fact it's worse than a goto since at least a goto had a label.

I'm not for or against exceptions just pointing out that a result or optional type is in no way at all similar to an exception.

On another point C++ exceptions are notoriously inefficient as well. There ware valid reasons to want to be exception free even from a code style perspective.

[snovv_crash]

I'd argue that pubsub systems are the modern goto, but exceptions certainly come in a not too distant second.

[smallstepforman]

When you wrote pubsub, did you mean “the observer design pattern”? If so, please try to adopt a more formal lexicon and use terminology familiar to more developers. If not, please describe what a “pubsub” is.

[snovv_crash]

No, I don't mean the observer pattern. I mean publisher subscriber pattern.

Observer pattern is fine, because there is still a link between the execution flow; basically any time you register a callback you're using the observer pattern.

Pubsub adds a middleware, typically in the form of a message passing framework, so that both publisher and subscriber aren't necessarily aware of each others existence. The publisher throws its data into the framework hoping someone finds it useful, and the subscriber listens for those messages hoping someone is publishing them. Think of it like multithread asynchronous goto of your execution flow, except with a lot more boilerplate.

[jpc0]

Wait I need to hear more about this.

How are pubsub systems a modern goto? Genuinely curious since I don't work with them directly that often

[snovv_crash]

If you give me a high level explanation about why goto is bad I can basically /s/goto/pubsub and it will still hold mostly true.

[qwery]

> why would you want to?

It seems like you know C++ pretty well, so I think you could probably come up with some reasons if you gave it a try.

The obvious thing that comes to my mind is because you can't rely on an undesirable, unknown, or potentially nonexistent implementation of the STL for your target platform.

As for cookies: who am I to dictate what/how someone should bake?

[112233]

As a person working in a large exception-free C++ environment, I'm all ears.

[pjmlp]

I assume you're making use of no-throw placement new and not touching any standard library type, whose error conditions as available only via exceptions as per ISO C++.

Otherwise good luck porting that exception free code across multiple OSes and C++ compilers, not only the big three.

[112233]

What standard library? ;)

There is a "turn code into object file using compiler" C++, that is much different from "committee vision" C++, and until recently (probably until initializer lists), -fno-exceptions -fno-rtti -ffreestanding did not emmit standard library symbols, except maybe static initialization.

Current C++ is being glued to library like crazy, look at continuations...

[pjmlp]

The one defined by ISO/IEC 14882 in a vault in Geneva.

[rockwotj]

Presumably they just use -fno-exceptions, and not everyone has to have portable code. I appreciate the concept but pragmatically there are plenty of C++ server side projects that only use Clang and GCC

[reactordev]

“-fno-exceptions“

Here-in lies the problem. This only says “no std::exception” “no throw” but nothing is stopping you from writing your own template for error handling. An exception is by definition a “unexpected condition” and we all have to handle exceptions in some form or fashion. Whether that’s with error codes, macro checks, or the like. That’s my point. Exception free code doesn’t exist. Safety guarantees are compile time at best. If this weren’t true, things like memory manipulation wouldn’t be possible. But it is. CheatEngine exists. Funnest thing is to read a var, set a var, and then check if the set var equals the set value or if it equals the old value. You just detected a memory pin cheat.

[diath]

I think you're terribly misguided here; when people discuss "no exceptions" here, they do not mean "any error handling that is not the typical/expected flow", they mean "getting rid of built-in exception system that comes with the heavy price of stack unwinding and the related mechanisms", not that they do not want to handle errors.

[pjmlp]

Yeah, and then come into twitter complaining when the code fails spectacularly after a compiler upgrade.