Object-oriented design patterns in the kernel, part 1 [LWN.net]

Object-oriented design patterns in the kernel, part 1

Posted Jun 16, 2011 8:11 UTC (Thu) by gowen (guest, #23914)
In reply to: Object-oriented design patterns in the kernel, part 1 by jond
Parent article: Object-oriented design patterns in the kernel, part 1

void somefunction() {
  do_something();
  do_something_else();
  important_cleanup_code();
}

Can do_something() fail for some reason? If so, why don't you check for it? If not, why do you think you need to worry about it throwing an exception?

Under what circumstances do you imagine that C++ do_something_cpp() will throw an exception but do_something_c() silently succeed?

(Log in to post comments)

Object-oriented design patterns in the kernel, part 1

Posted Jun 16, 2011 9:12 UTC (Thu) by elanthis (guest, #6227) [Link]

There's big differences.

A C-style error handler can fail without bringing down the rest of the system. An exception cannot. There's also different definitions of "fail" with different levels of consequences, while an exception is always a fatal error unless you explicitly check for it.

There's the matter of exception handling logic not being able to be placed where you might want it, too. With a simplistic C error handling facility I can store an error code and check it later when it matters or is most convenient. With exceptions, I need to wrap each individual function call (and operator, etc.) in order to ensure that nothing slips past.

Operator overloading, virtual functions, etc. are all massively useful features that help an unbelievable amount in writing good code. Exceptions just don't bring any meaningful benefit to large, complex programs that need to keep operating, don't bring any readability/maintainability benefit, and pretty much only appear to be beneficial when you look at tiny little trivial error handling examples compared to very poorly written C APIs. (Operator overloading is often panned, but anyone who's ever written a game in C with C-style math libraries can tell you that operator loading opponents are full of doody; and anyone who's ever tried a math library in Python/Lua/JavaScript/Ruby/Java/C#/etc. can tell you with five times the conviction that dynamic typing or static typing without local types that C++ critics are full of doody.)

Object-oriented design patterns in the kernel, part 1

Posted Jun 16, 2011 13:46 UTC (Thu) by gowen (guest, #23914) [Link]

There's the matter of exception handling logic not being able to be placed where you might want it, too. With a simplistic C error handling facility I can store an error code and check it later when it matters or is most convenient.

Wow. I am truly staggered ... just utterly lost for words. Exceptions/RAII automatically propogate non-recoverable errors to the correct level of abstraction, error return values have to be propogated by hand.

With exceptions, I need to wrap each individual function call (and operator, etc.) in order to ensure that nothing slips past.

Holy living Christ on a bicycle... Do you really think that's how to write code that uses exceptions for error handling? If you do, please stop writing about it, because you don't know what you're talking about.