Reformat the Exceptions

[Mustard2]

At the moment most if not all of the exceptions are dealt with a simple try/except

try:
  # code
except Exception:
  # error message and cleanup

Maybe it would be better to create a wrapper over it (for instance a decorator on the codes of block called) which gives also better error messages (which we can extract from the e in except Exception as e:)

@catch_exception
block_that_should_not_fail()

Or at least catch the exception in some standard way for more complex cases:

try:
  # code
except Exception as e:
  exception_error_message(e, "Specific error message")
  #    -> "MustardUI Error - " + "Specific error message" + " : " + str(e)
  # cleanup

[Mustard2]

@claude any hint?

[claude]

Claude finished @Mustard2's task in 1m 51s —— View job

---

Hints for Exception Reformatting

• Load tools
• Explore codebase for existing exception patterns
• Provide hints and guidance

---

Here's what I found after scanning the codebase (~65 try/except blocks across 30 files) and some practical hints:

What exists today

Three main patterns appear in the codebase:

1. Silent bare catch (~55 cases) — catch and fall back silently:

   except Exception:
       array_length = 0  # or pass, or fallback value

2. Operator error report (~10 cases) — already the good pattern:

   except Exception as e:
       self.report({"ERROR"}, f"MustardUI - Export failed: {e}")
       return {"CANCELLED"}

3. Debug-conditional print — common in UI/property code:

   except Exception as e:
       if addon_prefs.debug:
           print(f"MustardUI - Error while assigning pointer: {e}")

---

On the decorator approach

A @catch_exception decorator is tricky here because most of the errors are inside Blender operator execute() methods, which need self to call self.report() and must return {"FINISHED"} or {"CANCELLED"}. A decorator would need to inject or capture that context. It's doable but adds complexity that may not pay off for this codebase.

On the helper function approach (recommended)

A simple utility function in e.g. misc/ is more practical and fits how the codebase already works:

# misc/utils.py (or similar)
def mustard_report(operator, e, message):
    """Standard error reporting for MustardUI operators."""
    operator.report({"ERROR"}, f"MustardUI - {message}: {e}")

Then in operators:

except Exception as e:
    mustard_report(self, e, "Failed to load preset")
    return {"CANCELLED"}

For non-operator code (UI drawing, property evaluation) where there's no self.report():

def mustard_log(addon_prefs, e, message):
    if addon_prefs.debug:
        print(f"MustardUI - {message}: {e}")

---

Practical suggestion

Rather than a big refactor all at once, a good incremental approach:

1. Add the helper(s) in one small utility module.
2. Target operator execute() methods first — they're the most user-visible and the pattern is uniform (always have self, always return {"CANCELLED"} on error).
3. Leave silent fallbacks alone — the bare except Exception: pass/fallback cases are intentional defensive programming; capturing e there adds noise without value.
4. Standardize debug logging — the if addon_prefs.debug: print(...) pattern already exists in several files; a mustard_log() helper unifies the format.

The files with the most to gain from standardization are the operator files under presets/, custom_properties/, and configuration/ — those already use self.report() but inconsistently format the message string.

[Mustard2]

@claude is there a way to gather the error and create a new issue on github if the user wants it, giving the option. Please do not create a branch, just give hints

[claude]

Claude finished @Mustard2's task in 1m 10s —— View job

---

Hints: Error Reporting with GitHub Issue Creation

• Scan codebase for relevant patterns (URL opening, popups, error handling)
• Research the approach
• Provide hints

---

Yes, this is entirely doable within Blender — and the codebase already has all the primitives needed. Here's how the pieces fit together:

---

The key building blocks

1. GitHub pre-filled issue URLs

GitHub supports a URL format that pre-populates an issue form — no API key or authentication needed:

https://github.com/Mustard2/MustardUI/issues/new?title=<encoded>&body=<encoded>&labels=bug

Blender already has bpy.ops.wm.url_open(url=...) used in several places (the "Report Bug" button in settings/addon_prefs.py:78 already uses this). So opening a browser with a pre-filled issue is one line of code.

2. Full traceback capture

Python's traceback module gives you the full stack trace as a string — much more useful than just str(e):

import traceback

try:
    # code
except Exception as e:
    tb = traceback.format_exc()  # full traceback, same as what Python prints

3. URL-encoding the content

urllib.parse.quote() from the standard library encodes the traceback for embedding in a URL:

import urllib.parse
 Error: Failed to load preset")
body = urllib.parse.quote(f"**Describe what you were doing:**\n\n\n\n**Traceback:**\n```\n{tb}\n```")
url = f"https://github.com/Mustard2/MustardUI/issues/new?title={title}&body={body}&labels=bug"

4. The confirmation popup

Blender has two popup styles. The simpler one is context.window_manager.popup_menu():

def draw_popup(self, context):
    layout = self.layout
    layout.label(text="An error occurred. Do you want to report it?")
    layout.operator("mustardui.report_error", icon="URL")

context.window_manager.popup_menu(draw_popup,, icon="ERROR")

Or more interactively, an operator's invoke() can call wm.invoke_props_dialog(self) (as seen in armature/external/mhx/utils.py:221) which creates a modal dialog with OK/Cancel.

---

Practical pattern to consider

The cleanest approach for operators: a dedicated MustardUI_ReportError operator that stores the error state and opens the browser:

class MustardUI_ReportError(bpy.types.Operator):
    bl_idname = "mustardui.report_error"
    bl_label = "Report Error on GitHub"

    error_title: bpy.props.StringProperty()
    error_body: bpy.props.StringProperty()

    def execute(self, context):
        import urllib.parse
       
        body = urllib.parse.quote(self.error_body)
        url = f"https://github.com/Mustard2/MustardUI/issues/new?title={title}&body={body}&labels=bug"
        bpy.ops.wm.url_open(url=url)
        return {"FINISHED"}

Then in a catching block:

except Exception:
    import traceback
    tb = traceback.format_exc()
    # Show error in Blender's info bar
    self.report({"ERROR"}, "MustardUI - Preset load failed. Check the console for details.")
    # Queue the report operator (only works from execute, not from a draw callback)
    bpy.ops.mustardui.report_error(
        "INVOKE_DEFAULT",
        error_title="Error: Failed to load preset",
        error_body=f"**What were you doing?**\n\n\n\n**Traceback:**\n```\n{tb}\n```"
    )
    return {"CANCELLED"}

---

Important caveats

• URL length limit: Browsers (and GitHub) have URL length limits (~8,000 characters). A long traceback may need to be truncated. You can keep only the last N lines of the traceback or trim to a safe length.
• Operator context: bpy.ops.wm.url_open() works fine from an operator's execute(). From a UI draw callback or property update, you'd need to store the error somewhere (e.g., a Scene property) and trigger the open from a button instead.
• User opt-in: The pattern above immediately calls the operator, which opens the browser. A dialog first (ask "would you like to report?") is friendlier — this is where invoke_props_dialog would go, making the execute() method do the actual URL open only when the user confirms.
• Privacy: The traceback may contain local file paths. Worth noting in the issue body template or truncating paths to just the filename component.