Comment by zasdffaa | Hacker News Reader

Comment by zasdffaa | Hacker News Reader

Parent Full thread

Read this paper before and don't buy it.

   // c++
   if (condition1)
      throw my_exception1 ();

you throw an exception because you can't handle it locally. But then he says

   // C
   if (condition1)
      handle_exception1 ();

so if it can be handled locally in C it can also be in C++, so why throw anything?

Also, and I'm not a C++ guy (a little exposure many years ago) so someone correct me, but if you look at part 2 of this article (link at bottom to https://250bpm.com/blog:8/) he then complains about having to have helper data structures

   // c++
   class person
   {
       int age;
       int weight;
   };

   std::list <person*> people;

vs

   // C
   struct person
   {
       struct person *prev;
       struct person *next;
       int age;
       int weight;
   };

   struct
   {
       struct person *first;
       struct person *last;
   } people;

"First thing to note is that the C++ solution allocates twice the number of memory chunks compared to the C solution. For each element of the list there's a little helper object created." [he provides a diagram too]

But surely you can roll those helper objects into the main structure with templates - that is possible, right? OK, you don't use the library util 'std::list <person*> people' but still, it's possible and straightforward, right? Edit: and this was possible in 2012's version of C++ too I'm sure.

I don't get it, just use `list<person>`. The prev and next pointers live next to the person objects right in the same node, no need for intrusive pointer.

edit: The author assesses that this is somehow bad for person objects that are expensive to copy. But std::list has splicing operations, and since C++11 it has emplace as well, so this doesn't apply.

There's no way to use that optimization if you need to be in two or more lists at the same time.

Which is also an issue in the author's example, no? So the point would be moot.

Wouldn't std shared pointer handle that case?

Was it available when ZeroMQ was being planned? It's not a very new project.

boost shared_ptr has been around since 2001. ZeroMQ was started in 2007.

I honestly think exceptions will go down in history as a design mistake. Newer languages (eg Rust, Go) doesn't have them.

Exceptions make it incredibly difficult to be able to follow program flow. Most of the time you just log an exception and then either move on or exit. There's almost no actual handling of an except (other than maybe retrying). It gets even worse when people start using exceptions for control flow rather than errors.

One note about your example:

    > std::list <person*> people;

You wouldn't do this in C++. Why? Because ownership isn't clear meaning if people is cleaned up, it won't clean up the elements automatically. You could do:

    std::list<person> people;

but you have to be aware of copy semantics. You might do:

    std::list<std::unique_ptr<person>> people;

but that gets awkward too.

The differences between Go and Rust error handling is that Go doesn’t force you to handle its errors. Nothing bad happens if you just forget or don’t handle the error.

In Rust if you just unwrap it’s going to panic and in exception based languages it’s going to propagate until someone handles the error.

I personally don’t think Go error handling is going to go down in history as good.

I agree Rust's error handling is better and you can criticize some decisions in Go's error handling. I mean it also has these weird hybrid exception-like things (ie panics).

But the main point is that Go (and Rust) moved away from exception-as-control-flow that C++, C# and Java had adopted.

"exception-as-control-flow" is a misuse of exceptions. You can catch them just at strategic points and ignore them everywhere else.

I don't like Go error handling either (and I do like Rust) - but if the argument is against exceptions because of confusing flow, then there's a case for it in some languages I think - e.g. it's what you'd choose for Python if nobody had come up with exceptions (or they fell out of favour in time) for example.

Aside for not having to handle errors in Go, the type system itself makes error handling less useful. Rust's error handling is superior to Go's in every way I can think of.

It's literally impossible to write concurrent and highly-available code without exceptions.

You will be forced to write your own stack bubbling code. It's 2022, please don't write your own hand-made bespoke stack unwinding.

I think the GP was complaining that exceptions exist in the language, not suggesting that you can avoid them in C++. That’s why the other languages were listed.

> It's literally impossible to write concurrent and highly-available code without exceptions.

Do you have an example?

Yes, there was boost::intrusive_list for the latter since before 2012, for example.

C++'s throw lets you postpone handling of erroneous condition. You throw, then sort. You can postpone sorting of causes indefinitely, basically, up to the level where all of context needed is lost.

In C, you cannot throw. You have to handle. There will be more "if" statements, that's price to pay.

I work on code in C and C++ in more or less close problem domains and C++ provokes style and/or design that is much more hard to work with.

One of culprits is deep inheritance - once built, the inheritance structure cannot be changed. And I saw inheritance trees as deep as 10 recently. Instead of refactoring, I see copy-paste.

The point is not that you're handling an exception with some function, it's that knowing which function is being called to handle the exception becomes difficult to reason about.

This is the relevant line in the article:

> The problem with that is that you have no idea of who and where is going to handle the exception.

If you don't have a try/catch immediately around the throw, say at a higher level of where the function was called or, in the "worst" case, in the main body block, then the handling becomes hard to reason about.

I believe the argument is that reasoning about who handles which exception when is difficult and putting in logic to handle each individual exception at a higher level increases program complexity. Further, hunting back through the code to which piece of parent call handles the exception becomes increasingly difficult, especially if a function is called at different points with their own try/catch blocks.

The problem compounds because if you use classes, then there's no way to get around using exceptions as that's the only way to communicate that a constructor has failed. This means if you wanted to abandon C++ exceptions in favor of C-style error handling but still wanted to use classes, you would now need to mix and match C-style error handling with C++ style exception handling.

I don't quite see the argument against the class/struct <list> issue and I agree that this, from what I can tell, could be worked around and has better alternatives in C++ than they're making arguments against.

> The problem with that is that you have no idea of who and where is going to handle the exception.

I don't buy the argument.

By design exception handlers are handlers of exceptional events, which due to their exceptional nature either lead to a controlled recovery or controlled exit.

Once you're faced with your personal need to care enough about specific types of exceptions to the point they are no longer exceptional but a common occurrence, you're already mishandling exceptions at a fundamental level.

Consequently the solution is to not handle these expected cases as exceptions, or at most add try-catch next to the potential source of these commonly-occurring exceptions and don't let them leak beyond their source.

Exceptions are a kin to fire alarms and exception-handling is a kin to an organized evacuation plan. If you're misusing the fire alarm to the point you're complaining that you pull a particular fire alarm so often during your normal workflow that you start complaining you can't track badges during emergency evacuations, you should take a step back and take a long hard look at what you're doing, and how you're misusing that safety feature.

> By design exception handlers are handlers of exceptional events, which due to their exceptional nature either lead to a controlled recovery or controlled exit.

Exceptions are commonly used for events that are not really exceptional. In Java there is a precise distinction about them (checked vs unchecked exceptions), in C++ not.

Commonly libraries (not the C++ stl to be fair that rarely uses exceptions) use exception for things that are expected during a program execution: a file does not exist, a network socket closes, a resource is not available, the user interrupts the program, etc.

You may say: well, you should use exceptions for the first kind of error handling and error codes for the second, problem is that adds even more confusion, since you have some error conditions that may throw an exception and some other that may return an error code!

The simple solution is to not use exceptions at all, and the best way to do so is to use a language that doesn't have exceptions (such as C, but also Go, Rust, Zig, in general the trend for new languages seems to be to not have exceptions, and probably there is a good reason behind). While most C++ compilers let you can disable exceptions, but that will turn any throw of an exception into a panic or worse undefined behavior for code that uses them.

Especially in C++ exceptions are even implemented in a way that makes them more dangerous to use compared to other languages (such as Java):

- there is no indication about the fact that a method may throw an exception, rather there is the key noexcept that signal the contrary (that is all methods may throw exception except the one marked with noexcept, and there is no way to know which kind of exceptions a method may throw) - you are not forced to handle exceptions (in Java for checked exceptions you either handle them locally or have to declare in the signature of the method that it may throw exception) - exception introduce an hidden flow of control that may create various bugs impossible to spot (especially if this hidden flow of control passes trough libraries that you don't know what they do, and may for example have allocated resources that are not freed during the stack unwinding).

Having exceptions in low-level languages to me is a bad idea. Having them in higher level languages it's less of a bad idea because you have other form of protections, but still you can avoid them even there (I tend to not use exceptions in TypeScript, and prefer to return a Result type, and wrap any standard library function that may throw exception in this)

> in general the trend for new languages seems to be to not have exceptions

There is also a parallel opposite trend happening in (the obviously not mainstream) "effect" languages, such as koka and eff.

The new theory of algebraic effect handlers will probably trickle down to the new mainstream languages of the 2030's or 2040's.

I don't really know what to say. It's not that you're wrong or couldn't' be right, it's that there's a whole ecosystem of language and tooling, culture of idiomatic program design and human psychology at play.

So you draw a line in the sand and say that using exceptions for cases where errors are commonplace is fundamentally misunderstanding. Is this true for every library you use? For every programmer you're going to hire? For every scenario that you're going to encounter? Maybe, but it's asserting what reality should look like rather than what it actually is.

Arguments about which programming to use on a philosophical level are always hard because it's, in my opinion, effectively a psychological argument. The language provides intrinsics that allow you to think about problems in a certain way and use tools to help express ideas within that framework succinctly. So saying "this is a fundamental misunderstanding of what this intrinsic is there for" is kind of besides the point. How is it used? Does it's presence in the language make sense to use it in the way you think it should be used?

I actually don't have a big opinion on this, I was mostly trying to "strongman" the argument so that a better discussion could be had. I will point out that many more "modern" languages, like Go (and Rust?) use the more C-like error handling than the try/catch type error handling.

Exceptions are typically understood to apply to exceptional events that just shouldn't happen. The only language I know of that treats them as control structures is Python (ok, lisp as well come to think of, but they seem to be very different things from C++ exceptions. I have no experience with these).

> Arguments about which programming to use on a philosophical level are always hard because it's, in my opinion, effectively a psychological argument

If you treat them other than language convention expects, maybe that's a problem.

I have read up on the original exception designs and talked to the originator of these (Brian someone, I can't remember his surname). I believe I'm not misrepresenting him to say that he looked on exceptions as 'should never happen' events. However they have come to be seen as treating errors a bit more forgivingly (eg. network dropped) so in some cases a fresh attempt can be made. That seems reasonable.

As others have said, they're your last ditch attempt at doing something sensible, or perhaps trying to recover, when the impossible happens, so sqrt(-1) is an exception. Excepting because of a failure of a user to log in is not (true: that comes from a dr. dobbs article).

This is a good discussion https://en.wikipedia.org/wiki/Exception_(computer_science).

Doing a quick Google search, I see a paper by Stroustrup that looks to support your argument [0]. From the paper:

> One aspect of the exception handling scheme ... is that the default response to an error ... is to terminate the program.

While that may have been the intent, I'm arguing that how it's used is not that in modern C++.

For example, the constructor for `ifstream` throws an exception when encountering a problem trying to open a file [1]. There are many cases where this wouldn't fall under your definition of "exceptions should lead to termination". Whether this is "proper" C++ standard library ideology or not is beside the point. This is built into the language, used in a standard library and guiding programmers into an idiomatic way of using exceptions as error handling.

I imagine the C++ STL is rife with this type of idiom.

I'm really not a big fan of "you should read the article" type of arguments, especially when the article contradicts the point. From the Wikipedia article you link to, here some quotes that support my thesis:

> Kiniry writes that "As any Java programmer knows, the volume of try catch code in a typical Java application is sometimes larger than the comparable code necessary for explicit formal parameter and return value checking in other languages that do not have checked exceptions. ..."

> Exception handling is often not handled correctly in software, especially when there are multiple sources of exceptions; data flow analysis of 5 million lines of Java code found over 1300 exception handling defects.

> ... Weimer and Necula wrote ... that they "create hidden control-flow paths that are difficult for programmers to reason about".

These mostly relate to Java-style try/catch issues but I suspect they're at least somewhat valid for C++.

Again, I'm trying to make a good-faith argument. I see many situations where exceptions as understood by yourself and Stroustrup can lead to better quality code but I'm trying to highlight what the original article was talking about and try to see it from their point of view.

As with almost all of these arguments, there's an "it depends" clause. The arguments against exceptions in the article has an implicit "it depends on the context of creating my MQ library". The arguments in the comments are arguing against it without providing the necessary context.

[0] https://www.stroustrup.com/except89.pdf

[1] https://en.cppreference.com/w/cpp/io/basic_ios/exceptions

This is getting badly OT and I don't know how we got here. My original top post was saying if you don't need exceptions, why are you using them. They weren't necessary there so they should not have been used there. That is all. In this I am sure we agree.

> I don't really know what to say. It's not that you're wrong or couldn't' be right, it's that there's a whole ecosystem of language and tooling, culture of idiomatic program design and human psychology at play.

It seems you wanted to say that there are frameworks out there that use exception handling to handle flow control.

There are indeed. There's also plenty of fundamentally broken code around. That is not a justification to perpetuate mistakes. It's like someone complaining that sticking fingers in power outlets hurts because of the jolt. Well, then don't?

To me the two bits of code in the error handling case or not comparable. In the c++ case you would still handle the error in the if statement if it can be handled otherwise you would throw it. C++ has the advantages of giving you both options.

> If you don't have a try/catch immediately around the throw, say at a higher level of where the function was called or, in the "worst" case, in the main body block, then the handling becomes hard to reason about.

what exactly do you call "hard to reason about" ? if it's an exception most likely the library itself has no business handling it and should just let it propagate to the user of the library.

I don't want to be the user of a library that might do something even the library itself doesn't know why it happened.

Your point seems to be that any exeption that makes it to the top must by simple definition of reaching that point, have been something the user did or in some other way "not my problem", which I think is ridiculous.

The whole article starts with the assertion that they want this library to be solid not slapdash.

Reply on news.ycombinator.com