[Someone]

I agree with the 'make things const' part, but I would expect m_cachedWidth to be mutable. I'm too lazy to check that now, but if so, that would not help here.

Even if it is not, I still think this is an example of "how you should modify your code". Reason? Doing

  temp = foo();
  temp *= bar();
  m_member = temp;

keeps your state consistent in case bar() throws. I would even use it if bar() is known not to throw, because you can't know what the future will bring, and because what you 'know' sometimes isn't true. Defensive programming, if easy as in this case, is a net benefit.

[khuey]

Most low-level C++ projects (including Webkit and Gecko) don't use C++ exceptions.

[RogerL]

True enough, but we strive for consistent practice - coding in one way for project X, another for project Y, is error prone and doesn't scale. That handy dandy defrobolizer you wrote for WebKit? You can't really reuse it in another project without rewriting it to be exception safe. You should vary from good practices only when it makes sense, not use them only if you can make a case for using them in this specific instance. Anyone can come along later, eyeball your code, and understand your intent and see the potential problems. Magically code for a very specific environment? Good luck. Also, good luck when your next project requires exceptions or what have you, because you will be deeply out of practice coding for them.

Obviously the above can be taken too far, but programming for const correctness, mutability, and safety in the face of exceptions should be in everyone's toolkit, and the default way they program in C++ (IMO, naturally).