6 ms·

This sounds nice but is not true. The bigger the system is, the more value you get from exceptions. The cost is that cleanup operations have to be in destructo

by ncmncm 4y ago

This sounds nice but is not true. The bigger the system is, the more value you get from exceptions. The cost is that cleanup operations have to be in destructors. Do that, and exceptions demand almost no attention. Problems show up only when some prima donna declares throwing exceptions from what they call isn't allowed.

gravypod 4y ago
(Opinions are my own) Google uses absl::Status / absl::StatusOr as a replacement for what people would usually use exceptions for. The benefits: 1. As an end user of a large library I can tell you exactly which calls are "guaranteed" to succeed without learning anything else about the code. 2. It is impossible to ignore a Status/StatusOr which makes it impossible to ignore a failure. You have to explicitly ignore the return value which is easy to spot in code review. 3. You can return your exception across RPC an boundary with added detail so if a caller of your service. 4. You can (very easily) enrich the Status with metadata at every single point. So much so that it is very common. 5. You can enrich the way "exceptions" works in a way that makes sense for your company by changing the structure of Status. Cons: 1. It is more unnatural than dedicated syntax like try/catch. 2. You can't bubble exceptions up the stack automatically so there are macros that do this for you (https://cs.opensource.google/search?q=ASSIGN_OR_RETURN&sq= https://cs.opensource.google/search?q=ASSIGN_OR_RETURN&sq=)
- germandiago 4y ago
  1. you usually capture the most general exception in a lib and avoid all refactorings derived of can/cannot fail deep in a stack of calls that needs to be propagated all the way up. With status it happens the same as with stackless coro. Once something is like that, you need to propagate it all the way up. 2. an exception cannot be ignored either. 3. you can transform an exception into a value or even code them as values. 4. See nested_exception.
DannyBee 4y ago
You literally provide no evidence of your view, just assertions. Not even reasoned argument or examples. Just assertions. Assertions that lots of people who are serious experts in c++, library design, etc, are prima donnas. You see how that isn't particularly helpful or constructive to discussion, right? Maybe you'd like to at least point out the very large scale systems that are using and getting benefits from exceptions, as you claim exists? I can't personally name a single one.
- ncmncm 4y ago
  I hope we can all agree that we want the overwhelming majority of the lines of code we write, and of the cycles our programs execute, to be about solving an actual problem representing the purpose the program was written. Lines and cycles fooling with internal junk are overhead, waste. And, we want our functions to be small, do one thing, and be easily composed. The problem with Result and their ilk is that they pile on overhead at function-call boundaries, exactly the place where you need design to be fluid. The great insight behind C++ was that cleanup, packaged and applied automatically, eliminates opportunities for mistakes, freeing up our attention. Exceptions apply that to error handling by running the same, well tested code when errors happen, and gathering error events to a place where we are equipped to do something useful about them. Now that we often don't even need to code destructors anymore -- the compiler does it better -- our attention is freed for real-world problems. And, not needing to worry about propagating errors up the stack, we can focus on arguments and control moving down and results up. Attention is easiest to manage in a small program. There just isn't as much to think about. In a big program, with many people involved, it costs a lot more to deal with extra junk, choices about how to bubble errors out. Structuring error handling into destructors and exceptions provides a common framework that burns no discussion time. Everybody gets to concentrate on solving the actual problem, without distraction by incidentals. We would not be having this discussion if Google had not imposed its rule banning exceptions, which we know was imposed just to accommodate legacy code that did not have destructors. Now they have a thousand times as much code, still without good destructors. Wouldn't it have been less work to fix that code, then, than to impose its costs on everyone today?

by ncmncm 4y ago

gravypod 4y ago

(Opinions are my own) Google uses absl::Status / absl::StatusOr as a replacement for what people would usually use exceptions for. The benefits: 1. As an end user of a large library I can tell you exactly which calls are "guaranteed" to succeed without learning anything else about the code. 2. It is impossible to ignore a Status/StatusOr which makes it impossible to ignore a failure. You have to explicitly ignore the return value which is easy to spot in code review. 3. You can return your exception across RPC an boundary with added detail so if a caller of your service. 4. You can (very easily) enrich the Status with metadata at every single point. So much so that it is very common. 5. You can enrich the way "exceptions" works in a way that makes sense for your company by changing the structure of Status. Cons: 1. It is more unnatural than dedicated syntax like try/catch. 2. You can't bubble exceptions up the stack automatically so there are macros that do this for you (https://cs.opensource.google/search?q=ASSIGN_OR_RETURN&sq= https://cs.opensource.google/search?q=ASSIGN_OR_RETURN&sq=)

germandiago 4y ago
1. you usually capture the most general exception in a lib and avoid all refactorings derived of can/cannot fail deep in a stack of calls that needs to be propagated all the way up. With status it happens the same as with stackless coro. Once something is like that, you need to propagate it all the way up. 2. an exception cannot be ignored either. 3. you can transform an exception into a value or even code them as values. 4. See nested_exception.

DannyBee 4y ago

You literally provide no evidence of your view, just assertions. Not even reasoned argument or examples. Just assertions. Assertions that lots of people who are serious experts in c++, library design, etc, are prima donnas. You see how that isn't particularly helpful or constructive to discussion, right? Maybe you'd like to at least point out the very large scale systems that are using and getting benefits from exceptions, as you claim exists? I can't personally name a single one.

ncmncm 4y ago
I hope we can all agree that we want the overwhelming majority of the lines of code we write, and of the cycles our programs execute, to be about solving an actual problem representing the purpose the program was written. Lines and cycles fooling with internal junk are overhead, waste. And, we want our functions to be small, do one thing, and be easily composed. The problem with Result and their ilk is that they pile on overhead at function-call boundaries, exactly the place where you need design to be fluid. The great insight behind C++ was that cleanup, packaged and applied automatically, eliminates opportunities for mistakes, freeing up our attention. Exceptions apply that to error handling by running the same, well tested code when errors happen, and gathering error events to a place where we are equipped to do something useful about them. Now that we often don't even need to code destructors anymore -- the compiler does it better -- our attention is freed for real-world problems. And, not needing to worry about propagating errors up the stack, we can focus on arguments and control moving down and results up. Attention is easiest to manage in a small program. There just isn't as much to think about. In a big program, with many people involved, it costs a lot more to deal with extra junk, choices about how to bubble errors out. Structuring error handling into destructors and exceptions provides a common framework that burns no discussion time. Everybody gets to concentrate on solving the actual problem, without distraction by incidentals. We would not be having this discussion if Google had not imposed its rule banning exceptions, which we know was imposed just to accommodate legacy code that did not have destructors. Now they have a thousand times as much code, still without good destructors. Wouldn't it have been less work to fix that code, then, than to impose its costs on everyone today?