QDialog.exec()与open()的使用抉择：使用exec()替代open()的风险及规避措施咨询

Great question—let’s break down the context, risks, and workarounds here clearly.

Why Qt Docs Recommend open() First #

Qt’s official docs push for open() over exec() because exec() carries subtle bug risks, but let’s clarify what that means:

• open() is non-blocking: it shows the dialog and returns immediately, so you need to connect to signals like finished() to know when the user closes it. The catch? To access input values (like text from a line edit or combo box selection), you have to keep a reference to the QDialog instance that’s in the same scope as your finished() handler function. It’s doable, but adds extra boilerplate (signal connections, dedicated handler functions) that exec() avoids.
• exec() blocks the calling thread until the dialog closes. This means right after exec() returns, you’re still in the scope of the QDialog object—so you can directly grab any input values without dealing with signals. It’s way more convenient for simple use cases.

Wait, Qt Uses exec() Too? #

You’re right to point out that QGetOpenFileName uses exec() under the hood. So it’s not like exec() is a forbidden practice—it’s just that its convenience comes with tradeoffs that can bite you in complex apps.

What’s the Actual Risk of Using exec()? #

The main downsides of exec() stem from it starting a nested event loop:

• Unexpected event processing: The nested loop will process pending events (like timers, network replies, or slot triggers) that you might not have accounted for. For example, a background timer could fire multiple times while the dialog is open, or a network reply might trigger a slot that modifies state the dialog relies on—leading to hard-to-debug bugs.
• Perceived unresponsiveness: If your main thread has long-running tasks, exec() won’t fix that. Even though it processes events, heavy work in the main thread will still make the dialog feel frozen.
• Lifecycle mishaps: If you don’t manage the QDialog’s memory correctly (e.g., allocating it on the heap without a parent and forgetting to delete it), you could end up with memory leaks. Stack-allocated dialogs are safer here, but edge cases (like slots referencing the dialog after exec() returns) can still cause issues.

How to Use exec() Safely #

If you prefer exec() for its simplicity, here’s how to avoid the pitfalls:

• Stick to simple dialogs: Use exec() only for self-contained dialogs (like confirmation prompts, small settings panels) that don’t interact with ongoing background processes (network calls, worker threads).
• Avoid nested exec() calls: Never call exec() from a slot that was triggered by another dialog’s exec()—deeply nested event loops are a debugging nightmare.
• Manage lifecycle properly: Create the dialog on the stack whenever possible (it’ll be automatically cleaned up after exec() returns). If you need a heap-allocated dialog, assign it a parent widget or explicitly delete it once you’re done.
• Test edge cases: Make sure to test scenarios like the user closing the dialog via the window manager or pressing Escape—ensure your code handles these without leaving dangling state or crashing.

Final Takeaway #

exec() isn’t a "bad" method—it’s just a tool that needs careful use. For most simple, isolated dialogs, it’s perfectly safe and will save you from writing extra signal-handling code. For complex apps with ongoing background tasks, open() is the safer choice, as it avoids nested event loop surprises.

内容的提问来源于stack exchange，提问作者Llaves