Related to #9329. This does not claim to fix that issue, see the honesty section below.

What this changes

load_post ran three independent setup steps back to back with no isolation:

_apply_save_file_invariants(scene)
_apply_user_preferences()      # <- restores the BIM workspace
_install_viewport_overlays()

An exception anywhere in the first call silently prevents the BIM workspace restore from ever running. Blender swallows handler exceptions quietly, so there is no traceback for the user and no visible failure, just a missing workspace.

Each step now runs through a helper that catches and prints a warning plus traceback, so one failing step cannot skip the others.

Why this is relevant to #9329

Opening a model calls bpy.ops.wm.read_homefile() (bim/module/project/operator.py:1124), which replaces Blender's workspace set. Bonsai relies on _apply_user_preferences() in load_post to put the BIM workspace back (bim/handler.py:471-484). If anything before it throws, the workspace stays gone, which is exactly the reported symptom, including the absence of any error output.

Honesty about what is and is not proven

I did not reproduce the reported bug, and I did not identify which exception fires in the field.

I diffed the entire read_homefile to load_post to workspace-restore chain between v0.8.0 and v0.9.0. handler.py, bim/__init__.py (registration and handler order), the relevant parts of LoadProject, tool.Parametric.on_load_post, and data/workspace.blend are all identical between the branches. So the regression is not visible in this chain, and I cannot say why it appears on 0.9 specifically.

There is no compiled v0.9.0 wrapper available in my environment, so I could not run bpy.ops.bim.load_project_elements() or drive a real v0.9.0 session. A simulation of the sequence against the real workspace.blend on Blender 5.2.0 worked correctly, meaning the append and reactivate mechanism itself is not broken in isolation.

So: this is a structural fix for a failure mode that matches the report exactly, and it is worth having on its own merits, but it is not a confirmed fix for #9329. If someone can reproduce with a console open, the new warning should name the failing step, which would identify the real trigger.

Test

src/bonsai/test/bim/test_load_post_step_isolation.py, an AST contract test in the same style as the existing test_handler_forward_compat.py, so it needs no compiled wrapper. It asserts the three steps are not called bare from load_post and that all three are still invoked. Red against current v0.9.0, green after.

Related, not changed

The same "first exception kills the rest" shape exists one level down in tool.Parametric.on_load_post (bonsai/tool/parametric.py:291-299), where heal_stale_edit_flags(), discard_pending_previews(scene) and wall_offset_gizmos.clear_caches() run unguarded in sequence. Left alone to keep this change to one thing.

black and ruff clean.

Produced with AI assistance.