Question: This code is part of a class module.

```
Private pImg As Image 'For example, pImg = U_Cursor.Img

Public Property Let ItemID(ID As Byte)
    pImg.Picture = LoadPicture(ThisWorkbook.Path & "\Images\Img" & ID & ".gif")

    *ParentUserform*.Repaint 'ParentUserform is the userform I'm looking for
End Property

```

I have to force Excel to repaint the userform, otherwise the image sometimes doesn't update on screen. 

Is there a way to know which userform "pImg" is in?

If there is no efficient way to do it, I can add another variable to the class module containing the userform name, but I'd prefer not to.

Answer: 
Yes, in general it can.

First of all the operations that are customizable through the template arguments and that `std::accumulate` must perform can throw.

But even aside from that the standard does allow an implementation to throw implementation-defined exceptions if a standard library function does not have a non-throwing exception specification and the description of the function doesn't say otherwise, see [[res.on.exception.handling]/4](https://timsong-cpp.github.io/cppwp/n4659/res.on.exception.handling#4).

That being said, I would be surprised if the use of `std::accumulate` in your example would throw. There is no dynamic allocation required, so a potential throwing of `std::bad_alloc` should not be necessary and that is the most likely candidate for implementation-defined exceptions. The summation, copy and/or move operations on `int`s are also non-throwing.

In any case adding `noexcept` to a function does not cause undefined behavior if an exception is thrown inside of it. Instead it is well-defined that, should an exception reach the `noexcept` function's outer scope, `std::terminate` will be called, which by default abort the program, but can be customized to some degree.
There are preconditions on `std::accumulate()`, e.g., that the end of the range is reachable from the begin of the range. So far the standard library hasn’t put `noexcept` on functions with preconditions (at least, not in general; there may be special cases) as a debugging implementation could assert that there is a problem, e.g., by throwing an exception: what happens when undefined behavior is triggered is undefined and implementations are free to define any of that if they wish to do so.

Also, any of the functions called by `std::accumulate()` are allowed to throw, i.e., any `noexcept` declaration would need to be conditional. I think it is unlikely that the algorithms will get corresponding `noexcept` declarations in general.

As the specification doesn’t mention any case where `std::accumulate()` throws when called within contract, it won’t throw if none of the called operations throws.