OS Language Choice

[babernat]

Are there practical issues raised by using a language that has exception handling to develop an operating system? I was just thinking about this on the way in to work this morning and it seems like this might raise some issues. I've noticed some people say they're using C++ as their language, so I'm kind of curious as to what they'd say.

[JamesM]

Most people who use C++ for their kernels shun its exception handling. I must also say that a lot of people who use C++ in a hosted environment don't use its exception handling either...

[babernat]

Which kind of leads me to the (obvious?) conclusion that any type of exceptions in OS code (whether caught or not) is to be avoided.

The reason I'm thinking of this is because by trade I'm a Java programmer. The language uses exceptions liberally which is something I disagree with. Exceptions in general make code hard to analyze and debug. My logic being if I know something might go wrong, why would I not account for that case in my API instead of using an exception which could cause unforeseen problems, unecessary stack unwindng, etc.

just some random thoughts

[Colonel Kernel]

Which kind of leads me to the (obvious?) conclusion that any type of exceptions in OS code (whether caught or not) is to be avoided.

I think the reason it tends to be avoided in kernel code is due to its run-time overhead. Conceptually, it is possible to use it, just expensive.

The reason I'm thinking of this is because by trade I'm a Java programmer. The language uses exceptions liberally which is something I disagree with.

Exception specifications in Java make exceptions a lot more painful than they need to be. I've used exceptions in a lot of production code written in C++ and C# over the years and it's really made things easier to read and debug.

Exceptions in general make code hard to analyze and debug.

It's true that they prevent purely local reasoning when looking at code, but there are ways to mitigate this. For example, in C++ you can use the RAII idiom to ensure proper cleanup of resources in the presence of exceptions. Java lacks this facility, requiring the use of "finally" blocks. C# has "using" blocks, which are nicer than "finally" blocks, but still can't beat RAII in C++.

In terms of debugging, I think it actually helps in Java because you get a nice stack trace that shows you exactly where the failure occurred. In gnarly C code, it's hard to figure out which return code shows the symptom, or worse, was forgotten.

In my experience, if exceptions are used properly they make the code much more readable by focusing on the common case.

My logic being if I know something might go wrong, why would I not account for that case in my API instead of using an exception which could cause unforeseen problems, unecessary stack unwindng, etc.

Exceptions are part of any API that uses them.

[babernat]

Thanks for your insightful comments.

Exceptions are part of any API that uses them.

In terms of Java they are explicitly and implicitly. I say this because lately the trend has been to move away from checked exceptions and towards unchecked exceptions. While a checked exception is an explicit part of the API (you must catch it or else it is a "syntax" error although this is arguable in the purest form of syntax), unchecked exceptions are not required to be caught so it is an implicit part of the API.