>According to Anthony Barbachan:
>> The problem with exceptions (especially in the kernel):
>>
>> 1 - Error probably not handled locally in function, meaning the
>> function is relying on some higher level code to take care of the
>> exceptions.
>
>You may not realize that this is already true in C. In C the kernel
>says e.g. 'return -ENOENT'. That's not 'handling' the error at all!
>It's just *reporting* the error.
>
The fact that a caller function handles the the error code returned by a
function is handling the error locally. Having some function 3-whatever
levels higher in the calling chain handle the error leaves open a huge hole
that will allow many bugs to easily creep in (trowing un handled exceptions,
forgetting to handle an exception, etc), kills the modularability of the
code, and kill the easy readability/tracability that handling error codes
locally allows.
>Replace the 'return' with a 'throw' in C++, and nothing's different,
>except that it's effectively a multi-stack-frame return that's used
>to _report_ errors.
>
Function returns can report error just as well and more clearly.
Furthermore an error may not have to be handled for whatever reason;
returned error codes allows this.
>> 2 - Hampers readability as another programmer will find it difficult
>> to read the function and understand how it all works since the error
>> handling may be missing as it is suppose to be implemented at a
>> higher level.
>
>Use of exceptions makes error-handling logic less localized. But to
>the extent that the overall code is less cluttered as a result, the
>results can end up *more* readable.
>
The only errors that are logical to not be implemented locally are fatal
errors, all others should be handled locally so that the code code try and
correct the error.
>Besides, I believe in optimizing for maintainability, and easy
>browsing is only one factor in ease of maintenance. Far more
>important, IMO, is the ability to specify design decisions exactly
>once; careful use of exceptions can assist toward that goal.
>
This has been done just as well with function returns.
>> 3 - Exceptions also adds overhead, perhaps not speedwise, but
>> definately bloatwise.
>
>The word 'bloat' is unnecessarily pejorative; it's not bloat if it's
>actually useful.
>
Useful is if it gave me something that function returns didn't. Which would
be fine for fatal errors but the vast majority of errors aren't fatal.
>> 4 - Exceptions are one way, no way to continue executing if the
>> problem was resolved.
>
>Exceptions don't clean carpets or make coffee, either, but that
>doesn't make them useless.
>
But kills their usefulness in correcting errors.
>> 5 - Exception calls would be quite common as "errors" occur often in
>> the kernel.
>
>Which shows just how useful they would be! This is a point in favor
>of exceptions, not against them.
>
The rather large speed penalty of a trown exception makes this a point
against the use of exceptions.
>> >And STL iterators and algorithms *could* be useful for some kernel
>> >structures. You'd have to experiment to know for sure.
>>
>> The STL is messy. The syntax is atrocious and cryptic and error
>> messages are extremly cryptic due to the teplatization.
>
>"It's a fair cop, but society's to blame."
>
>The STL is single-mindedly general and orthogonal, which I find
>refreshing. Its design goals lead to tradeoffs in ease-of-typing and
>clarity-of-errors, which I can live with.
>
>> Besides to even use the STL you would have to reimplement it as the
>> kernel cannot call an external library.
>
>You'd just have to borrow some of the EGCS library and put it into the
>Linux 'lib' directory, so it's always available. No biggie.
>
It will be a biggy, the unswapable kernel will become much larger in size.
While I'm on this point, since templates are generate instataneous code for
any object that happens to use that templatized code, multiple copies of
what is esentially the same code will be generated; inflating the unswapable
kernel size even more.
>> The simplier, cleaner, more readable, safer, maintainable, and more
>> object oriented approach is to create classes that take care of
>> whatever needs to be taken care of.
>
>Readability, I'll grant you... :-/ But the STL *is* simple (in its
>thorough implementation of simple concepts), clean (in orthogonality),
>safe (in static type checking), and maintainable (by its helping you
>to localize your design decisions).
>
I have safe type checking in my regular container classes.
>Learn to appreciate the STL's strong points, and it'll help you.
>--
>Chip Salzenberg - a.k.a. - <chip@perlsupport.com>
> "When do you work?" "Whenever I'm not busy."
>
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu
Please read the FAQ at http://www.tux.org/lkml/