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?
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.
Related
Google C++ coding style recommends against C++ exceptions, and we don't use them too. For most of the STL library containers one can just ignore the exceptions, because normally they indicate critical errors and are difficult to handle anyway, so crashing is acceptable.
However there is a problem with multi-threading (std::thread), for example entering a non-recursive mutex twice throws an exception. This situation is not critical and could be handled by waiting.
My question is: anyone knows what is Google using as a threading library? Is there any C++ cross-platform threading library that doesn't use exceptions?
Thank you
It should be noted that Google's style guide does not not preclude the handing of exceptions rather the throwing of exceptions. I.e. deal with the problem, but don't make it any worse by throwing more exceptions.
In the case of re-entering a non-recursive mutex: that is clearly a programmer error rather than some unexpected bolt from the blue. The exception should be allowed to propagate up to the calling code so that it can be seen and dealt with as a bug. It should be noted that the Google Test framework does not rely on exceptions, but it can certainly catch and report them.
While Google's style guide takes an extreme position, there is no doubt that exceptions can highly problematic when writing reusable libraries. For example, we found developing with WinCE 6.0 that exceptions got sliced on re-throwing and on ARM platforms couldn't be reliably thrown across DLL boundaries. In addition, catching an exception could take several milliseconds, so they definitely shouldn't be used for non-exceptional circumstances (i.e. 'expected' errors) where real-time performance is required. The clue's in the name really.
The practices in Google's style guide dates back to the early nineties of the previous century, when threads were rather exotic beasts. As such, it doesn't make sense to wonder how that style and threads would mix. If you use "modern" (21st century) techniques like threads, you don't use Google's style guide and vice versa.
IIRC the reason that Google does not use exceptions is that much of their codebase is not exception safe, and they cannot afford to rewrite it.
From their site:
On their face, the benefits of using exceptions outweigh the costs, especially in new projects. However, for existing code, the introduction of exceptions has implications on all dependent code. If exceptions can be propagated beyond a new project, it also becomes problematic to integrate the new project into existing exception-free code. Because most existing C++ code at Google is not prepared to deal with exceptions, it is comparatively difficult to adopt new code that generates exceptions.
Given that Google's existing code is not exception-tolerant, the costs of using exceptions are somewhat greater than the costs in a new project. The conversion process would be slow and error-prone. We don't believe that the available alternatives to exceptions, such as error codes and assertions, introduce a significant burden.
Our advice against using exceptions is not predicated on philosophical or moral grounds, but practical ones. Because we'd like to use our open-source projects at Google and it's difficult to do so if those projects use exceptions, we need to advise against exceptions in Google open-source projects as well. Things would probably be different if we had to do it all over again from scratch.
Personally speaking I much prefer function return codes than exceptions. But regardless of one's own preferences or coding styles, the important thing is to catch problems where they occur, don't let them propagate, persist or cause mayhem.
What I do, especially during development, is on detecting any sort of error in any sort of thread I get the process to freeze itself. On Linux I raise the SIGSTOP signal. The benefit of that is that I can then attach with a debugger and see the whole process in all its broken glory.
The supposed ethos of C++ is "what you use, you pay for". However, this can be quite debilitating due to exceptions and their pervasive use in the STL.
Before anybody says "just turn exceptions on", life is not so generous with the programming environments we must live in. Mine is kernel programming where the execution environment does not provide enough C++ runtime to unwind the stack, etc.
STL containers will throw allocation failure exceptions when they cannot reallocate storage for their underlying backing stores. When exceptions are not enabled in the environment, the program will crash rather mysteriously: I have seen implementations straight-up abort or just assume that the allocation worked even if it did not.
Many C ADT libraries that I have come across deal with this problem upfront by returning an error code or having the error as an output parameter.
What is the "best" C++ way of dealing with this problem?
To clarify
I do not want to use the standard library, I cannot. I am not asking "how do I do that which cannot be done". I am asking: "given a clean slate, how should the container library be built."
That's easy: stop believing you should use the standard library for everything.
The standard library is intended to be the default place you go for functionality. However, that doesn't mean it is appropriate in every situation. Such as kernel programming, for example. This is a fairly niche environment, where you need direct and explicit control over things that the majority of C++ programmers don't care about.
The C++ standard mechanism for signaling failure, particularly of something like internal memory allocation from a container, is to throw an exception. The vast majority of applications will not bother to catch that exception; in the unlikely event that they are out of memory, they just die. Which is fine for them. Returning an error code in these cases is, at best difficult (consider reallocation of a std::vector<std::string>. What happens if one of the inner std::strings is what gets OOM? Who gets the error code? How would you even signal the failure of a constructor, since the exception is thrown by std::strings copy constructor?). And only people who really need to care will care enough to catch it.
You're working in a restricted environment, an environment that the standard library is not designed to handle. So... don't use it in that environment.
My suggesting is to track down a copy of EASTL. It's really designed for this sort of thing. The Github repo I linked you to has some bug fixes and so forth, but it's still mostly the same. It's not a bad bit of code. Their STL-like containers provide most of the interface, so they can be mostly drop-in replacements. But they provide special functionality to specifically control memory allocations. And they don't throw (or at least, you can turn off throwing).
It seems the problem is really your environment. Stack unwinding is not terribly complicated. I can see why you'd want to put some restrictions on it - throwing a 10 MB object is legal C++ - but even in kernel mode you should be able to support throwing std::bad_alloc through non-virtual calls.
With that in mind, the STL design is perfectly sane. The interface requires only minimal exception support, and the implementation can be tailored to the environment.
I have been programming in C++ on and off for about 5 years, why have I never seen exceptions used other than examples for examples sake?
Observation bias at work here.
A significant fraction of C++ code is for systems programming and embedded systems. (After all, C++ is just one of many options for applications programming, and many of the alternatives have fancier RAD environments, but in systems work, it's often the highest level language for which a compiler is available, by a wide margin). And most embedded systems as well as a significant chunk of systems development work have constraints that rule out exceptions.
If because of your focus, you tend to search out this sort of code, it's entirely possible that the C++ code you've seen doesn't use exceptions.
That doesn't mean that there isn't C++ code using exceptions -- there is, and a lot of it. It may just not appear in code designed to solve problems that are interesting to you.
Exceptions are a fairly late addition to the language, so I believe many C++ developers have never learnt to use them properly, and may feel more at ease using traditional (C style) error handling techniques.
I personally think they are indispensable in handling constructor failures (that is the foremost reason they were added to C++ after all), but they also require the correct use of other advanced (YMMV) techniques like RAII or smart pointers to avoid resource leaks.
I have been programming in C++ on and off for about 5 years,
why have I never seen exceptions used other than examples for examples sake?
I'm very curious about this.
I'm very curious about this since in 1996.
Sometime I think in 1996 C++ Exception Handling revolutionized the way I'm writing software.
I remember that I was reading about C++ Exception handling and I immediately understood the implications. Within minutes I was testing what happens, if an exception is thrown from a constructor.
Compilers for UNIX were not ready for C++ Exception Handling until G++ 3.0 I think (whe was this?).
Destructors were called for not constructed memory locations (on the stack) (in case of some exception was thrown).
Destructors were not called for successful constructed objects (on the stack) (in case of some exception was thrown).
delete was not called in case of an object created with new threw an exception from the constructor.
Compilers for Windows and OS/2 were ready in 1996/1997. They worked.
I remember Borland C++ for OS/2 and IBM CSet2 and Windows Visual C++.
Finally there was a method to abort construction of an object.
Finally one could allocate an object inside a constructor AND rely on the successful construction of this object in some other constructor.
Somehow I found out about all the rules. Not from books!
Years later books came out, claiming that C++ Exception Handling is a good way to catch array-out-of-bounds error or other problems for which I never stopped using assert.
Finally there was an easy method to provide the caller with complex information about some error without relying on stderr. Finally one did not need to debug some complex piece of software to find out, what was failing.
I cannot take people seriously, which are not using C++ Exception Handling.
It is impossible to check every fallible call.
It is impossible to reach the same level of quality of software without using C++ Exception Handling.
Why are such people still hired?
Why are there still platforms, which do not provide C++ Exception Handling.
I would never consider writing software for such a platform,
in the same way I would refuse writing a complex application in assembly code.
Curious. I work in C++ regularly, and it's been at least ten
years since I've seen any C++ code which doesn't use exceptions.
Anytime you have to propagate an error up a significant number
of stack frames, you use an exception.
Several reasons come to mind:
Exceptions shouldn't be very visible, since they are designed to be thrown deep in the bowels of a library and caught somewhere high up in the call stack (even as high as main()).
They are intended to signal exceptional (i.e., rare and unexpected) faults. For example, failure to open a file isn't particularly exceptional. So, by default, the iostream library doesn't throw an exception when it fails to open a file.
Exceptions are very expensive to throw, which encourages adherence to the design intent.
C++ libraries that throw exceptions don't interface easily with C programs.
I could say the same thing and it would not be biased a lot, if i define that this is true for a Microsoft world and RAD.
I think it is because today you don't use C++ programs per se but rather a mixture of high level language using C++ libraries. And often you have a managed-unmanaged boundary.
Throwing and catching exception through this boundary is like lighting a firecracker in you ass :) - [read mem leak or worse]
Moreover if you use COM objects you have to use COM exceptions, so the usage of standard C++ exception must reside internally in a often small library. In small libraries you dont have a need to use exceptions.
Because there is a huge discrepancy between "real-world" code and "text-book" code.
I work in a "large" software company and can honestly tell you that the stuff you see in production follows nearly 0% of the good practices you read about in good books.
Take Scott Meyers' Effective C++ book as an example. Should be a copy on every software engineer's desk, from east coast, to west.
Exceptions are too advance for beginners so these are not always shown in the examples, especially on books.
I'm speaking of desktop applications for Windows. In my observation (YMMV too), earlier phase of the development probably until initial releases. Many developers doesn't think of exceptions early on. That is why there are few codes with exception handling but if you had like 2 or 3 releases already or if your on maintenance phase, exceptions are being considered due to various deployment environments through error reports from customers.
Several reasons come to mind:
Exceptions shouldn't be very visible, since they are designed to be
thrown deep in the bowels of a library and caught somewhere high up
in the call stack (even as high as main()).
I don't know what you mean with "Exceptions shouldn't be very visible".
But I agree that catch-blocks should be rare -- and they are usually in main.
They are intended to signal exceptional (i.e., rare and unexpected)
faults. For example, failure to open a file isn't particularly
exceptional. So, by default, the iostream library doesn't throw an
exception when it fails to open a file.
that the iostream library does not throw exceptions makes it kind of unuseable.
Hiding errors from the caller!
This is so C like.
Exceptions are very expensive to throw, which encourages adherence
to the design intent.
Usually Exceptions are for system calls failing.
Since writing to a file or opening a file is not really inexpensive,
one would not care about Exceptions being expensive.
Also having to check for success is more expensive than using C++ Exception Handling.
Usually one would not create a try-catch block inside a time critical part of code.
C++ libraries that throw exceptions don't interface easily with C
programs.
What is C? Ah yes -- I remember -- something I gave up around 1996. Remember Turbo Pascal?
Exemptions are not used in examples because it is rarely the focus of many of the questions or something you want to know in the first place.
I was under the impression that using setjmp() and longjmp() in C++ was almost guaranteed to mess up the stack, since these functions don't perform unwinding like, say, exceptions do. This MSDN page, however, indicates that the Microsoft implementation can be told to invoke the destructors of local objects, which implies that careful use of these functions could be safe.
Is there a portable means of ensuring program correctness when using setjmp() and longjmp() in C++? Best practices in C++ indicate that exceptions are best not used for flow control, but in a situation that requires highly unusual flow (e.g., coroutines and closures), is it always preferable to use exceptions in lieu of these functions?
If you have some really weird requirement that doesn't allow you to control the flow of the program normally, with conditionals/loops/breaks, I would prefer to use an exception over jmp.
There are scenarios where using an exception to control flow is acceptable. I think one of Boost.Graph's search functions throws an exception to quickly return to the caller from deep recursion.
I've used them before, but only under one circumstance: I was creating an OS kernel in C for an OS class; they were used for exception handling.
My understanding is that they're used for exception handling when dealing with low-level code, like an operating system. For general C++ software, I'd just use try catch.
I've been given some Symbian C++ code to port over for use with the Android NDK.
The code has lots of Symbian specific code in it and I have very little experience of C++ so its not going very well.
The main thing that is slowing me down is trying to figure out the alternatives to use in normal C++ for the Symbian specific code.
At the minute the compiler is throwing out all sorts of errors for unrecognised types.
From my recent research these are the types that I believe are Symbian specific:
TInt, TBool, TDesc8, RSocket, TInetAddress, TBuf, HBufc,
RPointerArray
Changing TInt and TBool to int and bool respectively works in the compiler but I am unsure what to use for the other types?
Can anyone help me out with them? Especially TDesc, TBuf, HBuf and RPointerArray.
Also Symbian has a two phase contructor using
NewL
and
NewLc
But would changing this to a normal C++ constructor be ok?
Finally Symbian uses the clean up stack to help eliminate memory leaks I believe, would removing the clean up stack code be acceptable, I presume it should be replaced with try/catch statements?
I'm not sure whether you're still interested, but one possibility is that where the Symbian idioms are using the EUSER.DLL (i.e. TDesC derived classes, RPointer*, etc) you may find taking the open source EPL code from Symbian developer site and adding it directly into your port a viable option. That is port over the necessary bits of EUSER (and others perhaps?).
However, if your current code base already uses a lot of the other subsystems you're going to see this become very unwieldy.
You should try to read some introductory text on development for Symbian. They used to have some examples in the Symbian site, and I am sure that you can find specific docs on how the types you want are meant to be used and what they provide.
The problem is that symbian development has its own idioms that cannot/should not be directly used outside of the symbian environment, as for example the two phase construction with the cleanup stack is unneeded in environments where the compiler has proper exception handling mechanisms --in Symbian a constructor that throws can lead to all sorts of mayhem.
If this is not a very large codebase it may be easier/faster to start from scratch and doing everything Android style. Even if you require NDK/C++ this approach may be quicker.
Another approach may be to use portable C/C++ for the core, and the use this on both Symbian and Android version while doing UI stuff separately for each platform. Spotify have done this on Android and iPhone.
It would typically be a bad idea to try and port Symbian OS C++ to standard C++ without having a very good understanding of what the Symbian idioms do.
This could very well be one of these projects where the right thing to do is to rewrite most of the code pretty much from scratch. If you barely know the language you are targetting, there is little point in deluding yourself into thinking you won't make mistakes, waste time and throw away new code anyway. It's all part of learning.
The CleanupStack mechanism is meant to help you deal with anything that could go wrong, including power outage and out of memory conditions. Technically, these days, it is implemented as C++ exceptions but it covers more than the usual error cases standard C++ code normally handles.
Descriptors (TDesc, TBuf and HBuf all belong to the descriptor class hierarchy) and templates (arrays, queues, lists...) predate their equivalent in standard C++ while dealing with issues like the CleanupStack, coding standards, memory management and integrity...
A relevant plug if you want to learn about it: Quick Recipes On Symbian OS is a recent attempt at explaning it all in as few pages as possible.
You should also definitely look at the Foundation website to get started.
Classes prefixed by T are meant to be small enough by themselves that they can be allocated on the stack.
Descriptor classes suffixed by C are meant to be immutable (A mutable descriptor can usually be created from them, though).
HBufC is pretty much the only Symbian class prefixed by H. It should always be allocated on the Heap.
A method suffixed by C will add an object on the CleanupStack when it returns successfully (usually, it's the object it returns). It's up to the calling code to Pop that object.
Classes prefixed by R are meant to be allocated on the stack but manage their own heap-based resources. They usually have some kind of Close() method that needs to be called before their destructor.
A typical way to thing about the differences between a collection of objects and a collection of pointers to object is who owns the objects in the collection. Either the collection owns the objects when they are added and looses them when they are removed (and is therefore responsible for deleting each object it still contains when it is itself destroyed) or the collection doesn't transfer ownership and something else must ensure the objects it contains will stay valid during the collection's lifetime.
Another way to think about collections is about how much copying of objects you want to happen when you add/get objects to/from the collection.
Symbian descriptor and collection classes are meant to cover all these different ways of using memory and let you choose the one you need based on what you want to do.
It's certainly not easy to do it right but that's how this operating system works.