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.
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.
> 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.
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.
> 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.
> 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.
> 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.
> >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.
> 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).
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/