fix: add graceful error logging for BaseThread crashes

[aphrodoe]

Description

Problem or Issue being addressed

Currently, any class that inherits from BaseThread (which handles nearly all hardware listeners, camera loops, and scrolling UI text) can silently crash without yielding any errors or stack traces to the output, refer to issue #907.

Because the underlying loop encapsulates its execution in an isolated boundary, if a developer writes buggy code or an edge-case logic error occurs inside def run(self):, the thread terminates abruptly. It never halts the main UI/application event loop, but the targeted feature has zero trace output, which might make debugging harder.

Solution

By wrapping the subclass's inherited .run() method in a protective global try/except Exception: block at the instance level:

1. Crashing threads now securely log a full stack trace utilizing logger.exception.
2. The instance state gracefully exits by securely flagging self.keep_running = False.

Additional Information

MicroPython Portability: Since it natively preserves the threading.Thread inheritance hierarchy, it stays clean and is cross-compatible if there is MicroPython _thread port in the future.

Screenshots

Tried adding an intentional bug in class HorizontalTextScrollThread, it logs the exception properly. This will help in future dev workflows, rather than making it go unnoticed.

---

This pull request is categorized as a:

• New feature
• Bug fix
• Code refactor
• Documentation
• Other

---

Checklist

I ran pytest locally

• All tests passed before submitting the PR
• I couldn't run the tests
• N/A

---

I included screenshots of any new or modified screens

Should be part of the PR description above.

• Yes
• No
• N/A

---

I added or updated tests

Any new or altered functionality should be covered in a unit test. Any new or updated sequences require FlowTests.

• Yes
• No, I’m a fool
• N/A

---

I tested this PR hands-on on the following platform(s):

• Raspberry Pi OS Manual Build
• SeedSigner OS on a Pi0/Pi0W board
• Emulator

---

I have reviewed these notes:

• Keep your changes limited in scope.
• If you uncover other issues or improvements along the way, ideally submit those as a separate PR.
• The more complicated the PR, the harder it is to review, test, and merge.
• We appreciate your efforts, but we're a small team of volunteers so PR review can be a very slow process.
• Please only "@" mention a contributor if their input is truly needed to enable further progress.

• I understand

---

Thank you! Please join our Devs' Telegram group to get more involved.

Resolves #907
Part of Summer of Bitcoin

[S1DDHEY]

ACK
ran the provided test on current implementation, observed that it raises a ValueError, but it is not handled by BaseThread. After applying the PR changes, the same test passes, confirming that exceptions are now properly logged and thread state is updated.

[S1DDHEY]

One thought/suggestion that I have is dynamic reassignment of self.run.

Wrapping run() at runtime via self.run = wrapped_run can be a bit fragile and harder to reason about. Would it make sense to instead define a stable run() in BaseThread and delegate subclass logic to something like _run_impl()?

[aphrodoe]

Yes, that is indeed what I was originally intending to do with this PR. However, I realised it would require refactoring across many files. Any class that uses Basethread would have to use _run_impl() instead of run(). Since my main goal was bringing light to this, I did not want to do a big refactor. However, if the maintainers think this a viable problem to work on, I can do those changes too. They would just require a rename of run() to maybe a simpler name like _run() rather than _run_imp() across few files, and a placeholder definition for it with the same logic I have here.

[kdmukai]

This is a blind spot. I can't recall if it has caused me trouble during development in the past, but it seems very likely that it would have.

I had Claude take a look at our use of BaseThread and it came up with an alternate solution using a built-in Python feature that I had not been aware of:

(Copied from Claude, but curated to be human-friendly)

---

Alternative: threading.excepthook

Python 3.8+ provides threading.excepthook, a global hook that fires whenever any thread raises an unhandled exception. A single registration at startup replaces the need to wrap run() on each instance:

import threading
import logging

logger = logging.getLogger(__name__)

def thread_exception_handler(args):
    logger.exception(
        f"Thread {args.thread.name} ({args.thread.__class__.__name__}) crashed",
        exc_info=(args.exc_type, args.exc_value, args.exc_traceback),
    )

threading.excepthook = thread_exception_handler

Advantages over the instance-level monkey-patch

• Catches all Python-level threads, not just BaseThread subclasses. The codebase has at least one raw Thread (PiVideoStream) that this PR as currently written would miss.
• No monkey-patching.
• Standard, documented Python mechanism.

Limitations

The hook runs on the dying thread. It provides logging/debugging output but does not interact with or signal the main thread.

Global scope

threading.excepthook fires for all Python-level threads, including any spawned by third-party libraries. SeedSigner's current dependencies (Pillow, embit, pyzbar, picamera) don't appear to spawn Python threads that would create noise.

But if preferred, the handler can be filtered to only act on BaseThread instances:

def thread_exception_handler(args):
    if not isinstance(args.thread, BaseThread):
        return
    logger.exception(
        f"Thread {args.thread.name} ({args.thread.__class__.__name__}) crashed",
        exc_info=(args.exc_type, args.exc_value, args.exc_traceback),
    )