add new category in libs/libraries.htm
Any opinions on adding a new category in libs/libraries.htm, Error Reporting, containing static_assert and the exception lib? Emil Dotchevski Reverge Studios, Inc. http://www.revergestudios.com/reblog/index.php?n=ReCode
As I said before, I think that's perfect. On Mon, Jul 28, 2008 at 8:22 PM, Emil Dotchevski <emil@revergestudios.com>wrote:
Any opinions on adding a new category in libs/libraries.htm, Error Reporting, containing static_assert and the exception lib?
Emil Dotchevski Reverge Studios, Inc. http://www.revergestudios.com/reblog/index.php?n=ReCode _______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
-- Alp Mestan --- http://blog.mestan.fr/ --- http://alp.developpez.com/ --- In charge of the Qt, Algorithms and Artificial Intelligence sections on Developpez
on Mon Jul 28 2008, "Emil Dotchevski" <emil-AT-revergestudios.com> wrote:
Any opinions on adding a new category in libs/libraries.htm, Error Reporting, containing static_assert and the exception lib?
I have a small objection. Or maybe not-so-small. Assertions are for precondition violations -- they detect programming errors. Exceptions are for failure to satisfy postconditions. They're really very different. If we are going to group these things under a single category, I'd like it if the name were more clear about its scope. I have several ideas but none is definitively better... -- Dave Abrahams BoostPro Computing http://www.boostpro.com
On Mon, Jul 28, 2008 at 3:47 PM, David Abrahams <dave@boostpro.com> wrote:
on Mon Jul 28 2008, "Emil Dotchevski" <emil-AT-revergestudios.com> wrote:
Any opinions on adding a new category in libs/libraries.htm, Error Reporting, containing static_assert and the exception lib?
I have a small objection. Or maybe not-so-small.
Assertions are for precondition violations -- they detect programming errors. Exceptions are for failure to satisfy postconditions. They're really very different.
Since we don't have a category for detecting and reporting failures, it seems a good idea to create one. I'm all for a better name for it, of course. The problem is that the exception lib doesn't belong in any of the existing categories, except maybe the Miscellaneous category. :) Emil Dotchevski Reverge Studios, Inc. http://www.revergestudios.com/reblog/index.php?n=ReCode
on Mon Jul 28 2008, "Emil Dotchevski" <emil-AT-revergestudios.com> wrote:
On Mon, Jul 28, 2008 at 3:47 PM, David Abrahams <dave@boostpro.com> wrote:
on Mon Jul 28 2008, "Emil Dotchevski" <emil-AT-revergestudios.com> wrote:
Any opinions on adding a new category in libs/libraries.htm, Error Reporting, containing static_assert and the exception lib?
I have a small objection. Or maybe not-so-small.
Assertions are for precondition violations -- they detect programming errors. Exceptions are for failure to satisfy postconditions. They're really very different.
Since we don't have a category for detecting and reporting failures, it seems a good idea to create one. I'm all for a better name for it, of course.
The problem is that the exception lib doesn't belong in any of the existing categories, except maybe the Miscellaneous category. :)
Well, maybe that's where it belongs. static assert and Boost.Test are in the category of something like "program validation and testing" and don't belong in the same category as something designed for dealing with resource exhaustion and other essentially non-preventable and (hopefully) recoverable conditions. -- Dave Abrahams BoostPro Computing http://www.boostpro.com
On Mon, Jul 28, 2008 at 4:43 PM, David Abrahams <dave@boostpro.com> wrote:
on Mon Jul 28 2008, "Emil Dotchevski" <emil-AT-revergestudios.com> wrote:
On Mon, Jul 28, 2008 at 3:47 PM, David Abrahams <dave@boostpro.com> wrote:
on Mon Jul 28 2008, "Emil Dotchevski" <emil-AT-revergestudios.com> wrote:
Any opinions on adding a new category in libs/libraries.htm, Error Reporting, containing static_assert and the exception lib?
I have a small objection. Or maybe not-so-small.
Assertions are for precondition violations -- they detect programming errors. Exceptions are for failure to satisfy postconditions. They're really very different.
Since we don't have a category for detecting and reporting failures, it seems a good idea to create one. I'm all for a better name for it, of course.
The problem is that the exception lib doesn't belong in any of the existing categories, except maybe the Miscellaneous category. :)
Well, maybe that's where it belongs. static assert and Boost.Test are in the category of something like "program validation and testing" and don't belong in the same category as something designed for dealing with resource exhaustion and other essentially non-preventable and (hopefully) recoverable conditions.
Yes, exceptions are used to enforce postconditions, but this doesn't contradict the view that exceptions are used to report failures (to meet postconditions). There are different kinds of failures, but despite the differences there is some commonality between asserts, static asserts, exceptions, signals, std::cerr, logging, abort(), exit(), etc. Naming a category "error reporting" seems to capture that, and it seems more descriptive than "miscellaneous" (and from that point of view static assert would belong to both "error reporting" and "program validation and testing".) Emil Dotchevski Reverge Studios, Inc. http://www.revergestudios.com/reblog/index.php?n=ReCode
on Mon Jul 28 2008, "Emil Dotchevski" <emil-AT-revergestudios.com> wrote:
Assertions are for precondition violations -- they detect programming errors. Exceptions are for failure to satisfy postconditions. They're really very different.
Since we don't have a category for detecting and reporting failures, it seems a good idea to create one. I'm all for a better name for it, of course.
The problem is that the exception lib doesn't belong in any of the existing categories, except maybe the Miscellaneous category. :)
Well, maybe that's where it belongs. static assert and Boost.Test are in the category of something like "program validation and testing" and don't belong in the same category as something designed for dealing with resource exhaustion and other essentially non-preventable and (hopefully) recoverable conditions.
Yes, exceptions are used to enforce postconditions,
"Enforce" isn't the best word; they bail you out when you're not going to meet postconditions, so you can avoid failure.
but this doesn't contradict the view that exceptions are used to report failures (to meet postconditions).
You might notice that I said "exceptions are for failure to satisfy postconditions" above :-) That said, they're really for avoiding failure, as noted in this message.
There are different kinds of failures,
Radically. And people tend to collapse them in their minds.
but despite the differences there is some commonality between asserts, static asserts, exceptions, signals, std::cerr, logging, abort(), exit(), etc. Naming a category "error reporting" seems to capture that, and it seems more descriptive than "miscellaneous" (and from that point of view static assert would belong to both "error reporting" and "program validation and testing".)
How about "diagnostics?" -- Dave Abrahams BoostPro Computing http://www.boostpro.com
On Mon, Jul 28, 2008 at 5:57 PM, David Abrahams <dave@boostpro.com> wrote:
You might notice that I said "exceptions are for failure to satisfy postconditions" above :-)
That said, they're really for avoiding failure, as noted in this message.
There are different kinds of failures,
Radically. And people tend to collapse them in their minds.
Yes, you're right to be concerned about this.
but despite the differences there is some commonality between asserts, static asserts, exceptions, signals, std::cerr, logging, abort(), exit(), etc. Naming a category "error reporting" seems to capture that, and it seems more descriptive than "miscellaneous" (and from that point of view static assert would belong to both "error reporting" and "program validation and testing".)
How about "diagnostics?"
You're right that "diagnostics" describes the commonality I was talking about better, but it implies that the failure at hand is abnormal, that something is broken and needs to be fixed. Throwing an exception doesn't necessarily indicate abnormality, in fact the program might rely on the exception to operate properly (for example, if you're processing a sequence of files, you might want to catch(eof &) and open the next file to be processed.) So I think that "reporting" fits better, since it's more neutral than "diagnostics." Emil Dotchevski Reverge Studios, Inc. http://www.revergestudios.com/reblog/index.php?n=ReCode
Emil Dotchevski wrote:
Throwing an exception doesn't necessarily indicate abnormality, in fact the program might rely on the exception to operate properly (for example, if you're processing a sequence of files, you might want to catch(eof &) and open the next file to be processed.)
That doesn't sound like a good idea, given how exceptions are implemented: a fast normal execution path and a slow recovery path. They indicate erroneous situations which you can live with. Something bad happened, but you can live with it and recover from it. The most usual case is failure to acquire a resource. They cannot be disabled due to the fact you cannot predict without running the program whether the situation will occur or not. Here is my opinion about the rest: Runtime asserts indicate conditions and invariants that were not fulfilled, that is to say a promise that was not fulfilled by the programmer, or a bug. So they're really programming errors. They're only useful for debug builds, even though fairly often exceptions are used for cases that ought to be runtime asserts, which is bad IMO (Java throws when dereferencing a null pointer, numerous Boost utilities throw when used while being empty...) Static asserts is similar to runtime assert, except it checks a compile-time property. It's really the same thing, except that usually people do not bother to disable them outside of debug builds, since they only occur at compile-time. Both kinds of asserts are very useful for testing the validity of a program. Static asserts especially, since they do not require a specific dynamic state to be reached. The difference between exceptions and asserts are that, while both are errors, exceptions is a system to report error and asserts is a system to check that errors do not occur. So the Error Handling category could be subdivided in Error Reporting (which would also contain error codes and logging) and Error Checking (which would also contain the testing framework).
on Tue Jul 29 2008, Mathias Gaunard <mathias.gaunard-AT-ens-lyon.org> wrote:
Emil Dotchevski wrote:
Throwing an exception doesn't necessarily indicate abnormality, in fact the program might rely on the exception to operate properly (for example, if you're processing a sequence of files, you might want to catch(eof &) and open the next file to be processed.)
That doesn't sound like a good idea, given how exceptions are implemented: a fast normal execution path and a slow recovery path.
Sometimes that's exactly the tradeoff you need.
The difference between exceptions and asserts are that, while both are errors, exceptions is a system to report error and asserts is a system to check that errors do not occur. So the Error Handling category could be subdivided in Error Reporting (which would also contain error codes and logging) and Error Checking (which would also contain the testing framework).
That might be a good idea. -- Dave Abrahams BoostPro Computing http://www.boostpro.com
David Abrahams wrote:
on Tue Jul 29 2008, Mathias Gaunard <mathias.gaunard-AT-ens-lyon.org> wrote:
The difference between exceptions and asserts are that, while both are errors, exceptions is a system to report error and asserts is a system to check that errors do not occur. So the Error Handling category could be subdivided in Error Reporting (which would also contain error codes and logging) and Error Checking (which would also contain the testing framework).
That might be a good idea.
Actually logging is more "error checking" I guess, since you cannot catch the error and recover from it in the program.
on Wed Jul 30 2008, Mathias Gaunard <mathias.gaunard-AT-ens-lyon.org> wrote:
David Abrahams wrote:
on Tue Jul 29 2008, Mathias Gaunard <mathias.gaunard-AT-ens-lyon.org> wrote:
The difference between exceptions and asserts are that, while both are errors, exceptions is a system to report error and asserts is a system to check that errors do not occur. So the Error Handling category could be subdivided in Error Reporting (which would also contain error codes and logging) and Error Checking (which would also contain the testing framework).
That might be a good idea.
Actually logging is more "error checking" I guess, since you cannot catch the error and recover from it in the program.
Logging seems to me to be about reporting. "Reporting" doesn't say anything about recovery to me. -- Dave Abrahams BoostPro Computing http://www.boostpro.com
On Wed, Jul 30, 2008 at 7:55 AM, David Abrahams <dave@boostpro.com> wrote:
on Wed Jul 30 2008, Mathias Gaunard <mathias.gaunard-AT-ens-lyon.org> wrote:
David Abrahams wrote:
on Tue Jul 29 2008, Mathias Gaunard <mathias.gaunard-AT-ens-lyon.org> wrote:
The difference between exceptions and asserts are that, while both are errors, exceptions is a system to report error and asserts is a system to check that errors do not occur. So the Error Handling category could be subdivided in Error Reporting (which would also contain error codes and logging) and Error Checking (which would also contain the testing framework).
That might be a good idea.
Actually logging is more "error checking" I guess, since you cannot catch the error and recover from it in the program.
Logging seems to me to be about reporting. "Reporting" doesn't say anything about recovery to me.
Right, even if what's being reported in a log is an error (sometimes it's not) the reporting itself is neutral and has no effect on the program execution. In other words, the "error checking" that leads to the action of logging isn't really part of the logging, in my mind. Emil Dotchevski Reverge Studios, Inc. http://www.revergestudios.com/reblog/index.php?n=ReCode
participants (4)
-
Alp Mestan -
David Abrahams -
Emil Dotchevski -
Mathias Gaunard