0

Let's suppose we are developing a store, and, depending on the session state, the user is allowed to do different things. For example, suppose a widget must be blocked during a while in some specific moment, because some specific user actions, and the user tries again.

Of course, the most obvious implementation will be launching an exception in the corresponding function (the specific event handler), to say the action is currently blocked. That's similar to a concrete problem of mine. In that case, it was more convenient for me, instead of throwing an exception, make the function a "no-op", but emiting a boost::signal2's signal. The GUI does whatever he wants to do, inform the user or whatever. But perhaps the GUI only wants to inform the user once, so, it just disconnect to the signal after the first call.

And I liked it. It's pretty beautiful and elegant: to make it a no-op and emit a signal. No stack unwinding, functions can be marked as noexcept, you enable more optimizations in consequence, and you deal with the excepcional cases only when you want, connecting and desconnecting to the signals as wished.

Now it comes the question, what if I want to generalize the method substituting each exception for signals? even for non-GUI applications?

In that case, are boost::signals2 more inneficient than exceptions? Because it's a common hearing that try/catch blocks, no-noexcept functions, and stack unwinding causes overhead and avoid the compiler do a lot of possible optimizations. On the other hand, boost::signals2 is thread-safe, which causes extra overhead.

Is it my idea a bad idea at all?

I hope my question is not close for being "too broad" or "opinion-based", because its a question of design (and optimization) after all; although not too much specific, I have to admit.

Note: The GUI is a website. The thing is, I'm using Wt, a library to do websites in C++, which translate a hierarchy of widgets and signals to HTML/Javascript/Ajax, and my long-term project is to create a suite for creating GUIs in both, desktop/mobile (Qt) and web (Javascript) from a common infrastructure with an unique C++ back-end. Wt allows a mapping between C++/Javascript slots for a same event; for example, a click: if Javascript or Ajax is not available, the event is sent to the server and the C++ slot is called. If it is available, the event is executed on the client using the Javascript version. In case a same (GUI) event has more than one slot, the order of execution of slots is unspecified, and if both slots are C++ calls, they could be even executed in parallel on the server if there's enough threads available in the thread pool.

ABu
  • 10,423
  • 6
  • 52
  • 103
  • 2
    Signals are not a replacement for exceptions. They work in a completely different way. If you need signal semantics, use signals. If you need exception semantics (such as stack unwinding, and orderly class destructions), you won't get it from signals. Unless you have a controlled signal environment, where only the execution thread can send a signal to itself, so the signal handler is completely thread safe, in which the signal handler itself can throw an exception. But then, what's the point of that? Now, explain why a function call cannot do what you want your signals do? – Sam Varshavchik Sep 19 '16 at 12:33
  • The only performance critical path is the test of an error/exceptional/signal condition. –  Sep 19 '16 at 12:42
  • If a user can't currently perform a task, the corresponding user interface element should be disabled or even hidden. Nothing to do with either exceptions or signals. – user207421 Sep 19 '16 at 12:53
  • @SamVarshavchik I agree with you. Specially for constructors, you need exception semantics if the construction cannot be done. Make an answer with some examples of situations where exception semantics are requiered, and I'll mark your answer as valid. – ABu Sep 19 '16 at 13:21
  • @EJP In my case, at least, I cannot be sure if the GUI has been "blocked" when the request arrives. – ABu Sep 19 '16 at 13:29
  • Unclear. When the request arrives from what? If the GUI has been disabled correctly the request *can't* arrive. – user207421 Sep 21 '16 at 00:46
  • You are right, unclear. I've added just now a note at the end of the question to give a little of context. If a click event, for example, has two actions: blocking the GUI and process something which can be executed only once, it could happen that the "do-something-important()" slot is called before the GUI is blocked, new requests could be sent by a "mistaken" double click, or a malicious attacker which modifies the javascript code. And add the fact that slots execution order is unspecifed. All of that together makes impossible to be sure the GUI is disabled correctly. – ABu Sep 21 '16 at 01:36

0 Answers0