The SB API's tend to take SBError as an in/out parameter for the cases where the function in question naturally returns some other value, and return an SBError when there's no other logical return value.
So in these cases it would be more in line with the general practice to return an SBError. OTOH, I really don't like the practice of adding "Ex" or other similar function name decorations to get around the fact that C++ doesn't overload on return values. IMO they make the API harder to remember. And especially since we really should use the error version, so you will end up with the primary function having this weird tag as part of the name... In balance I think adding it as an argument is better, but this is one of those cases where I would leave it to the taste of the implementor... Jim > On Jun 20, 2018, at 9:09 AM, Adrian Prantl via Phabricator > <revi...@reviews.llvm.org> wrote: > > aprantl added a comment. > > This patch is adding new overloads to SBAPI calls that don't return an > SBError, such as: > > // Old: > void StepOutOfFrame(SBFrame &frame); > // New: > void StepOutOfFrame(SBFrame &frame, SBError &error); > > I wonder if it would be easier to use and more consistent with the rest of > the API if we instead added an overload that returns an SBError, like this: > > // New: > SBError StepOutOfFrameWithError(SBFrame &frame); > // Alternative names that are just as ugly. > SBError StepOutOfFrameE(SBFrame &frame); > SBError StepOutOfFrame2(SBFrame &frame); > > @clayborg, @jingham: What do you think? > > > https://reviews.llvm.org/D47991 > > > _______________________________________________ lldb-commits mailing list lldb-commits@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
