CODEWITHSUNDEEP
c++qtexception
user200783
user200783

Reputation: 14348

Qt is not exception safe. How does this impact C++ code?

Qt is not currently exception safe nor, it seems, is it ever likely to be. What restrictions does this place on C++ code which interacts with Qt?

Do I need to avoid all C++ exceptions in my code if I want to use Qt?

Upvotes: 3

Views: 427

Answers (1)

abarnert
abarnert

Reputation: 365717

You can do the same two things you do with any other non-exception-safe library that you want to use in an application: Isolate it in exception-safe wrappers, or give up exceptions and adapt to its style. What you're really asking is whether the first is feasible.

For your literal question, you definitely don't need to avoid all exceptions. All of the Qt functions that return error codes, classes that don't clean themselves up properly, etc. can be wrapped up pretty easily. And you have no good reason to throw exceptions at Qt, so it doesn't matter that you can't. And you don't often pass Qt objects to non-Qt libraries that depend on exceptions. And so on. The trickiest it gets it thinking about how to write, e.g., a QImage wrapper that will destroy and throw if the real constructor succeeds with an invalid value, and that's not very hard.

But the big issue is that you can't throw exceptions through signal-slot connections. If you wanted to organize your code in the typical way, where low-level functions throw most of the exceptions and top-level functions do most of the exception handling, but you want to use Qt as most of your middle layer, that's probably not going to be pleasant.* For, say, a traditional heavy-controller MVC design, where most of the controller is built on Qt, your use of exceptions is going to end up being very local and not be all that helpful. On the other hand, with a MVA design or a smart-model design, most of your logic may not be dealing with Qt directly at all, so you can still go wild with exceptions within pretty large boundaries. (Of course that assumes you don't use Qt where you don't have to.)

* Even here, it's possible to wrap things up. For example, you can't throw across a thread join, condition wait, etc., but you can build futures and executors that pass exceptions between threads in a clean way. With the same kind of scaffolding, you could pass exceptions through slots. But that's reasonably heavy scaffolding, and you'll end up with a pretty different API than a typical Qt program, so it doesn't seem worth it.

Upvotes: 4

Related Questions