Hacker News Reader

Comment by reactordev | Hacker News Reader

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.

View on HN

> 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.

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

> 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.

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

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

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.

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.

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.

Reply on news.ycombinator.com