Re: Are so many subclasses such a good idea?
On 13 Jun., 03:32, kh...@yahoo.com wrote:
Hi folks,
I noticed that the standard library has a bunch of
classes like std::bad_alloc, std::runtime_error
that derive from std::exception.
I gather that in order to use one of these error
classes, one creates an instance of that subclass,
whichever is appropriate.
?es. Or you create a new subclass deriving from one of those classes
(or from std::exception).
But is this really a good design practice?
Yes. The principle is to have one class for each error, and one class
for each group of errors. So you could have a class math_error and
derive e.g. overflow from this. Then if you wish to handle math
errors, you catch matherror but if you only wish to handle overflow
situations, you catch overflow.
It seems odd to create subclasses for
different situations. Why didn't they create
methods for each situation instead?
I do not see what is odd here. You catch via a class name, not a
methodname. The alternative would be to have some extra data attached
to the generic class and examine that code. This quickly converts to
an if-else ladder or a case which is quite errorprone:
try
{
....
}
catch (overflow const& of)
{
....
}
becomes:
try
{
....
}
catch (matherror const& me)
{
if (me.type == "overflow")
{
....
}
else
{
throw;
}
}
/Peter
--
[ See http://www.gotw.ca/resources/clcm.htm for info about ]
[ comp.lang.c++.moderated. First time posters: Do this! ]