OSDev.org

MakaAlbarn001 wrote:The problem there is that without exception support and rtti, classes aren't usable, without some very tricking programming.

vvaltchev wrote:I agree with @kzinti that it's not worth the effort to support C++ exceptions in a kernel.

I'll add that, from my personal point of view, it's probably better this way. Even if the code is more verbose (with error codes), in my experience it's easier to not handle an exception properly by mistake than to not check for the return value of function. In the kernel, you should be concerned about every detail and every corner case. In userspace you can just say that in certain cases we might fail in a generic way and even handle the crash of a child process. In the kernel, you should try to make crashes impossible to happen. Every failure (even hardware failures!) should have a safe handling. With exceptions, too many things can go wrong, for example when throwing code is called in destructors.

For many years the C++ code in the Joint Strike Fighter program didn't use exceptions at all, not because it was technically hard to do that (most of that software runs in userspace), but because it wasn't safe to do so. Recently, as far as I know, they started to use exceptions in a very limited way. So, I genuinely believe that kernel code should be written "as if" you'll die if your kernel crashes. That should be the quality level. And indeed, as you get more and more programs to run on your OS and they interact with each other, even small and apparently innocent bugs amplify and have terrible effects. So, that quality level becomes mandatory to keep a complex system in a stable condition.


Said that, even if I believe the "C mindset" is more appropriate for kernel development, you can certainly have some benefits by using C++. For example, RAII and templates. I decided that my kernel will use mostly C, but I implemented two files in C++ because it was more elegant to use templates than several copy-pasted macros with minor differences.

nullplan wrote:I recently saw a talk about error handling in C, and it basically advocated for returning error codes from functions in addition to anything else by way of structs (just return small structs by value), and then passing those error codes back into all the following functions so they can abort early. For example, when opening a file, the file opening function returns a structure that contains the file and a "valid" (or "error code") word. You then pass that structure into further functions, which return early if the file is not valid. That avoids the weird control flow you get from testing error codes, as well as the "goto fail" problem OpenSSL popularized, and you do not have to deal with the idiosyncrasies of setjmp()/longjmp().

std::expected<MemoryMap*, efi::status_code> ExitBootServices();

efi::status_code efi_main(...)
{
    ...
    auto memoryMap = ExitBootServices();
    if (!memoryMap)
    {
        // Handle error, accessible at memoryMap.error();
        return memoryMap.error();
    }

    // Use memory map
    memoryMap->Print();
}

thewrongchristian wrote: I also much prefer exception based error handling, and also include macro based try/throw/catch in C using setjmp/longjmp, which mostly works well. But the stack unwinding is the pain with this, as I have to install handlers to unwind any objects that need unwinding properly (like synchronisation objects), and this is cumbersome as well. I do have a facility to add "finally" blocks to try blocks, which can do this cleanup, but this is again added code that can be forgotten.

thewrongchristian wrote: It's just nicer to have a C++ compiler generate the extra code for you in both cases, so I'd dearly love to move to C++ and C++ exceptions, but the stumbling block being having to get this unwinding working in the kernel, and I've not tried portng the unwinding yet.

There is no reason why properly supported C++ exceptions shouldn't be used if supported, if you're careful to make your code exception safe.