In the work I was doing with the scripted ThreadPlans & Breakpoint Callbacks,
I've been introducing Status objects into these calls in python-wrapper.swig
(usually you have to start from the ScriptInterpreter API's, so we can report
errors. That way I could catch errors with wrong number of arguments and the
like. Whenever that's possible it seems preferable.
Jim
> On Oct 28, 2019, at 7:28 AM, Pavel Labath via Phabricator
> <revi...@reviews.llvm.org> wrote:
>
> labath added inline comments.
>
>
> ================
> Comment at: lldb/scripts/Python/python-wrapper.swig:64
>
> + unsigned max_positional_args = PythonCallable::ArgInfo::UNBOUNDED;
> + if (auto arg_info = pfunc.GetArgInfo()) {
> ----------------
> lawrence_danna wrote:
>> labath wrote:
>>> Is there any case where fetching the argument info will fail, but we still
>>> can successfully call the target object? Should we just bail out here?
>> probably not? My thinking is that since there's no meaningful way to
>> return an error from this function we may as well try to call it and let the
>> exception get logged. But I dunno. Should I change it?
> Hmm... In that case, I think it would be better to print the error which
> caused the ArgInfo fetching to fail. Given that, in the new way of doing
> things, the `PyErr_Cleaner` object is not going to work anyway, we might as
> well use this opportunity to create a different mechanism for printing
> exceptions.
>
>
> Repository:
> rG LLVM Github Monorepo
>
> CHANGES SINCE LAST ACTION
> https://reviews.llvm.org/D69468/new/
>
> https://reviews.llvm.org/D69468
>
>
>
_______________________________________________
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
