Caught `hasattr()` error re-raised in `DAObject.__getattr__`

[jpagh]

Edited:

When there's some kind of error with a dunder method, docassemble doesn't raise the right error, making it hard to diagnose the issue, in this case a caught hasattr() error.

Reproduction

YAML:

---
objects:
  - test_obj: DAObject
---
mandatory: True
question: |
  Bug Reproduction — Stale `pending_error`
subquestion: |
  Step 1: ${ hasattr(test_obj, 'nonexistent') }
  Step 2: ${ test_obj.__custom__ }
---

Result:

Interview has an error. There was a reference to a variable 'test_obj.nonexistent'
that could not be looked up in the question file (for language 'en') or in any of
the files incorporated by reference into the question file.

Docassemble seeks a question for test_obj.nonexistent which was only ever checked via hasattr(). The actual expression is test_obj.__custom__.

Expected result:

An error about test_obj.__custom__, not the caught hasattr() error about a different variable.

[jhpyle]

The suggested fix breaks the docassemble logic system.

This seems like AI-generated text and the AI text is not helping me understand what changes I might need to make to the code and for what purpose.

Could you tell me what you were trying to achieve when you encountered an issue that stopped you from doing something you wanted to do? I might be able to accommodate more uses of attributes that begin with __, or I might need to update the documentation to tell people not to use attributes that begin with __.

[jpagh]

Hey, yeah that's what I was afraid of (this breaking docassemble), but I wasn't sure exactly, and doing a local override in my __getattr__ fixed the particular issue I was having.

I was getting errors for an Individual's use_familiar attribute not being defined in the interview, and it was because of the hasattr() in the Individual's __str__ method and then another, presumably dunder method, having an issue (I assume), but docassemble that was returning the use_familiar error and not the dunder method's error. The only dunder methods that I was using were shadowing built in dunder methods like str, getattr, and setattr, which seem like reasonable and necessary sometimes.

The reproduction yaml does reliably show the error I was experiencing.

Is there a way to maybe guard against hasattr() errors getting stored in the pending error? I know it technically is because hasattr just catches the attribute error, but it probably shouldn't be stored here to get accidentally reported.

Sorry about the AI dump. I wasn't sure if I should drop the whole thing or just the reproduction yaml to bring up the issue. I'll keep it narrow next time.