Topic: Standard Exceptions library & Third-party library exceptions
Author: abell@mindspring.com (Andrew Bell)
Date: 1998/04/17 Raw View
On 15 Apr 1998 15:11:29 GMT, Xavier Huet
<xavier.huet@sophia.siemens-scg.com> wrote:
> 1) what is the purpose of domain_error ?
I would assume that it's to indicate a problem with the domain: that
is, the input for a function. For example, if you were writing an
operator[] for an array-like object, an index outside the legal values
for array indices could be handled by throwing a domain exception.
Of course, I've been wrong before.
Andrew Bell
[ comp.std.c++ is moderated. To submit articles, try just posting with ]
[ your news-reader. If that fails, use mailto:std-c++@ncar.ucar.edu ]
[ --- Please see the FAQ before posting. --- ]
[ FAQ: http://reality.sgi.com/austern_mti/std-c++/faq.html ]
Author: Xavier Huet <xavier.huet@sophia.siemens-scg.com>
Date: 1998/04/17 Raw View
Valentin Bonnard wrote:
> Xavier Huet wrote:
> Good question: it isn't thrown from anywhere in the library
>
> > 2) Why bad_alloc, bad_cast, bad_typeid are not in these
hierarchy.
> > (or if they are, where do they stand ?)
i forgot bad_exception but you got it !!!
>
>
> They derive from exception.
>
> Logically bad_alloc is a runtime error, bad_cast, bad_typeid are
> logic errors.
>
> The problem with runtime_error and logic_errors is that they use
> the string class. You can hardly avoid bad_alloc, bad_cast,
> bad_typeid (or you must stop using new, dynamic_cast, and exceptions
> spec in all your code and library code you use), but you may want to
> avoid the cost of the string code (embeded programming).
>
> So for purely code size reasons, these three exceptions X don't
> derive from Y where X IS-A Y.
>
So why they design runtime_error & logic_error as exception (ie
withoutthe
string code) ?
And do really avoid the coest of the string cost since we have
somewhere the what() string ?
> > 3) Do I have to plug my own exception hierarchy into these
standard
> > exception hierarchy (advantages, disavantages) ?
>
> Advantage: inheriting from a common base class lets you handle
> all exceptions easilly.
>
> try {
>
> }
> catch (exception& e)
> {
> cout << e.what () << endl;
> }
>
> I'd like to, but I have a problem: exceptions don't derive
> virtually from each other. So I can't inherit from MyException
> and logic_error at the same time to have MyLogicError, as
> MyException already inherit from exception:
>
> exception
> (v) / \ v
> / \
> logic_error MyException
> \ /
> \ /
> MyLogicError
>
> where (v) means 'should be virtual, IMO'
So what's the answer to my question ?
What is the guideline ? Do I have to forget the standard exceptions and
designed my own exceptions hierarchy completely apart ?
exception MyComponentException
/ /
/ /
logic_error /
\ /
\ /
\ /
OneOfMyLogicComponentError
Can it be a solution of your problem above ? ( I have 2 main branches :
one for the standard C++ lib, one for my Component Exception)
Is there a good guideline for designing a good exception hierarchy on
the
net ?
Thanks in advance,
------------------------------------------------------------------------
-------
Xavier Huet
Software Engineer
Siemens HL Sophia-Antipolis
Email : xavier.huet@sophia.siemens-scg.com
Tel : (33) (0) 4-93-00-27-07
Fax : (33) (0) 4-93-00-27-99
---
[ comp.std.c++ is moderated. To submit articles, try just posting with
]
[ your news-reader. If that fails, use mailto:std-c++@ncar.ucar.edu
]
[ --- Please see the FAQ before posting. ---
]
[ FAQ: http://reality.sgi.com/austern_mti/std-c++/faq.html
]
[ Send an empty e-mail to c++-help@netlab.cs.rpi.edu for info ]
[ about comp.lang.c++.moderated. First time posters: do this! ]
---
[ comp.std.c++ is moderated. To submit articles, try just posting with ]
[ your news-reader. If that fails, use mailto:std-c++@ncar.ucar.edu ]
[ --- Please see the FAQ before posting. --- ]
[ FAQ: http://reality.sgi.com/austern_mti/std-c++/faq.html ]
Author: Xavier Huet <xavier.huet@sophia.siemens-scg.com>
Date: 1998/04/15 Raw View
Hi all,
we are designing a set of components in C++. We want to use exceptions
to report errors. We know about the Standard exceptions :
exception
logic_error
domain_error
invalid_argument
length_error
out_of_range
runtime_error
range_error
overflow_error
underflow_error
These exceptions are thrown by the Standard C++ library.
Let's say that we want to design a File Class. We will have different
exceptions for
example : TooManyFileDescriptor, AccessRight , ...
1) what is the purpose of domain_error ? at the same time, can you
explain all
the exception hierarchy (it's very short in the draft).
2) Why bad_alloc, bad_cast, bad_typeid are not in these hierarchy.
(or if they
are, where do they stand ?)
3) Do I have to plug my own exception hierarchy into these standard
exception hierarchy (advantages, disavantages) ?
4) If answer 3) is yes, what is the guideline. Do I have to derive
from domain_error ? (and runtime_error for TooManyFileDescriptor) ? Is
there a guideline available to design a good exception hierarchy ?
Thanks in advance,
-------------------------------------------------------------------------------
Xavier Huet
Software Engineer
Siemens HL Sophia-Antipolis
Email : xavier.huet@sophia.siemens-scg.com
Tel : (33) (0) 4-93-00-27-07
Fax : (33) (0) 4-93-0027-99
[ comp.std.c++ is moderated. To submit articles, try just posting with ]
[ your news-reader. If that fails, use mailto:std-c++@ncar.ucar.edu ]
[ --- Please see the FAQ before posting. --- ]
[ FAQ: http://reality.sgi.com/austern_mti/std-c++/faq.html ]
Author: Valentin Bonnard <bonnardv@pratique.fr>
Date: 1998/04/15 Raw View
Xavier Huet wrote:
> we are designing a set of components in C++.
Me too.
> We want to use exceptions
> to report errors. We know about the Standard exceptions :
> exception
> logic_error
> domain_error
> invalid_argument
> length_error
> out_of_range
> runtime_error
> range_error
> overflow_error
> underflow_error
>
> These exceptions are thrown by the Standard C++ library.
Correct
> 1) what is the purpose of domain_error ?
domain_error reports an error with a domain ;-)
Good question: it isn't thrown from anywhere in the library
> 2) Why bad_alloc, bad_cast, bad_typeid are not in these hierarchy.
> (or if they are, where do they stand ?)
They derive from exception.
Logically bad_alloc is a runtime error, bad_cast, bad_typeid are
logic errors.
The problem with runtime_error and logic_errors is that they use
the string class. You can hardly avoid bad_alloc, bad_cast,
bad_typeid (or you must stop using new, dynamic_cast, and exceptions
spec in all your code and library code you use), but you may want to
avoid the cost of the string code (embeded programming).
So for purely code size reasons, these three exceptions X don't
derive from Y where X IS-A Y.
> 3) Do I have to plug my own exception hierarchy into these standard
> exception hierarchy (advantages, disavantages) ?
Advantage: inheriting from a common base class lets you handle
all exceptions easilly.
try {
}
catch (exception& e)
{
cout << e.what () << endl;
}
I'd like to, but I have a problem: exceptions don't derive
virtually from each other. So I can't inherit from MyException
and logic_error at the same time to have MyLogicError, as
MyException already inherit from exception:
exception
(v) / \ v
/ \
logic_error MyException
\ /
\ /
MyLogicError
where (v) means 'should be virtual, IMO'
--
Valentin Bonnard mailto:bonnardv@pratique.fr
info about C++/a propos du C++: http://pages.pratique.fr/~bonnardv/
[ comp.std.c++ is moderated. To submit articles, try just posting with ]
[ your news-reader. If that fails, use mailto:std-c++@ncar.ucar.edu ]
[ --- Please see the FAQ before posting. --- ]
[ FAQ: http://reality.sgi.com/austern_mti/std-c++/faq.html ]