LLVM Programmer’s Manual

Re:LLVM Programmer’s Manual by pjc50 on Friday July 22, 2016 @05:22AM (#12142536)

The real failure is that return types must be declared by exceptions need not be and generally aren't. So an exception can come teleporting through any part of your code. You can no longer enforce single return style, because any expression can return.

This means that writing state-modifying code becomes unreasonably difficult, as you can no longer just write:

  // A and B must be kept in sync and updated together
  A = computeA()
  B = computeB()

.. because it's possible that computeB() throws an exception, leaving the two out of sync.

Yes, there are ways round this involving temporary variables. So you write:

  tmpA = computeA()
  tmpB = computeB()
  A = tmpA, B = tmpB;

and home that neither an optimiser nor an intern removes the tmp variables. But wait! This still doesn't work, because your evil coworker has defined operator= on B to throw an exception!

Personally I don't think that exceptions work very well in the presence of mutable state. Without mutable state, they're exactly equivalent to

[ Parent | on HN ]

Re:LLVM Programmer’s Manual by barrkel on Friday July 22, 2016 @06:22AM (#12142710)

This is an irreducible complexity if any part of your computation can fail. You're simply ignoring the error cases if you pretend otherwise.

Exceptions with mutable state needs to be coded transactionally, yes, and this is an excellent reason to try and avoid mutable state and use persistent data structures where possible.

[ Parent | on HN ]

Re:LLVM Programmer’s Manual by pjc50 on Friday July 22, 2016 @10:21AM (#12143653)

> You're simply ignoring the error cases if you pretend otherwise.

.. which makes using the STL surprisingly hard, because you can get an out of memory exception all over the place.

[ Parent | on HN ]

Re:LLVM Programmer’s Manual by Chris_Newton on Friday July 22, 2016 @10:55AM (#12143898)

In theory, yes, but if system-level errors like running out of memory or other essential resources are realistic possibilities in your particular environment then those risks are what they are. Exceptions don’t do anything fundamental to change that situation, they just (sometimes) provide a more explicit and/or systematic way of dealing with those errors if they occur.

In practice, I think this issue gets far more attention than it deserves, particularly within the C++ community. If you’re running in a particularly resource-constrained environment where running out is a relevant problem, you probably already take precautions about how you allocate those resources and adjust how you structure your program accordingly. You’re trying to avoid any possibility of those errors occurring, which means you don’t then have to worry about dealing with them unexpectedly all over your code.

For me, the more interesting discussing is around how we deal with errors that can be properly recognised and handled within normal execution. That means the interesting exceptions are those we throw ourselves and those deliberately thrown by other modules that we depend on, which we hope will be documented with each module’s interface. These things don’t just go off arbitrarily in just about any line of code we write, and they can be systematically structured, and we can write code that controls where mutations and other effects happen and where exceptions happen and how they interact.

[ Parent | on HN ]

Re:LLVM Programmer’s Manual by konstmonst on Friday July 22, 2016 @06:05AM (#12142676)

You are just using the worng pattern. Use Computation a; Computation b; use(a, b); Then if the computation aborts in b, then computation a will be cleaned up as intended.

[ Parent | on HN ]

Re:LLVM Programmer’s Manual by pjc50 on Friday July 22, 2016 @10:19AM (#12143643)

My second point is that with exceptions you can't guarantee the assignment of two objects, because the assignment operator can throw.

[ Parent | on HN ]

Re:LLVM Programmer’s Manual by plorkyeran on Friday July 22, 2016 @10:41AM (#12143794)

This was somewhat of a problem in C++03 because writing a copy assignment operator that can't fail is sometimes impossible, but I have never encountered a scenario where I was unable to make move assignment noexcept.

[ Parent | on HN ]