Re: safer stl
From: SaltPeter (SaltPeter_at_Jupiter.sys)
Date: 07/14/04
- Next message: SaltPeter: "Re: Trouble with non-default constructors"
- Previous message: Stephen Tyndall: "Re: Which Language ??"
- In reply to: Chris Val: "Re: safer stl"
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
Date: Tue, 13 Jul 2004 22:40:22 -0400
"Chris Val" <chrisval@bigpond.com.au> wrote in message
news:118880b0.0407130130.17d18619@posting.google.com...
> "SaltPeter" <SaltPeter@Jupiter.sys> wrote in message
news:<6XoIc.1300$TB3.183112@news20.bellglobal.com>...
> > "Edo" <edwardoJE@aking.com> wrote in message
> > news:40f1ec6c@dnews.tpgi.com.au...
> > > Hello
> > > since the STL does not use error handling, there have been "safe" STL
> > > introduced, is that something that I should use at least during
software
> > > development?
> > > e.g. somthing like STLport or safeSTL by Cay Horstmann.
>
> [snip]
>
> > As far as error handling is concerned, returning a bool as an error
> > condition from some function when an error occurs is the old way.
>
> It has definately been used for a long while - there is no
> doubting that, but returning a boolean value is still quite
> useful in many circumstances.
Absolutely. If anything, i'm hoping the OP sees that error conditions need
not only be processed at a given function's result. But you're already aware
of that. The goal was to provide a simple method to create and manage error
conditions on the fly. In other words, you don't have to rely on an
implementation's exception support.
>
> In regards to your post, I have a few corrections to make,
> and few opinions to throw - I hope you don't mind ? :-).
Of course not, its to the OP's benefit. And to mine as well.
>
> > Exceptions are designed to catch errors as well as unexpected errors.
Take
> > this simple rudimentary example of how to try, throw and catch an
exception
> > class in response to an out_of_range vector access. Note the try block
and
> > the catch blocks as well as the throw statement which "throws" an
instance
> > of the Err class.
>
> [snip]
>
> > int main()
> > {
> > try {
> >
> > std::vector<int> v;
> >
> > v.push_back(0);
> > v.push_back(1);
> >
> > for (int i = 0; i < 3; i++)
> > {
> > if(i > v.size() -1)
>
> You are comparing signed 'vs' unsigned values between 'i'
> and 'v.size()', which in turn returns:
> 'std::vector<int>::size_type'.
>
> You should change that to:
> for( std::vector<int>::size_type i; ...............
good point.
>
> > throw Err("vector range error"); // throw...
>
> I can understand what you were trying to demonstrate.
>
> For the benefit of the OP and other readers, I would like
> to demonstrate this taking a slightly different approach,
> which makes use of the standard library, and in particular,
> the features of 'std::vector' that help catch such errors.
>
> For example, when you attempt to access a vector outside
> of it's range of stored values, an *out_of_range* error
> occurs naturally when accessed via the '.at(n)' member.
>
> See my example at end of the post:
>
> > std::cout << "v[" << i << "] = " << v[i] << std::endl;
> > }
> >
> > return 0;
> > } // end try block
> >
> > // Err catch block
> > catch(Err& r_e)
>
> You should try to catch by const reference, if you're
> not going to attempt to modify the properties of the
> exception object.
i agree, however i preferred keeping it simple for the OP's benefit. The
catch block should indeed have been written:
catch (const Err& r_e)
{
// process and report
}
>
> > {
> > r_e.report();
> > return -1;
>
> Non portable return value.
>
> It is preferable to use the 'C' macro:
>
> # include <cstdlib>
> return EXIT_FAILURE;
>
> ...which will return an implementation defined value.
>
> > }
> >
> > // unexpected catch block
> > catch(...)
> > {
> > std::cerr << "unknown exception generated\n";
> > return -1;
>
> Same here...
> # include <cstdlib>
> return EXIT_FAILURE;
>
> > }
> > }
>
> The following example aims to demonstrate what happens, and
> how to deal with errors that exceed the bounds of a std::vector.
>
> I should also make it clear to newbies reading this, that the
> 'std::out_of_range' exception will only be thrown when using
> the '.at(n)' member function, and not when accessing the vector
> through the subscript operator '[n]'.
I'll repeat what he said, only with at() member function.
>
> Here is a very quick sample I put together:
>
> # include <iostream>
> # include <ostream>
> # include <vector>
> # include <stdexcept>
> # include <exception>
>
> int main()
> {
> try
> {
> std::vector<int> V;
>
> V.push_back( 0 ); // Ok ...
> V.push_back( 1 ); // Ok ...
>
> V.at( 2 ) = 100; // Oops! - There is no element at
> // the index position of '2'.
> }
> catch( const std::out_of_range& e )
> {
> std::cout << e.what() << '\n';
> }
> catch( ... )
> {
> std::cout << "Error: Unknown exception generated\n";
> }
>
> return 0;
> }
>
> -- OUTPUT --
> index out of range in function: vector:: at(size_t)
> index: 2 is greater than max_index: 2
>
> Cheers.
> Chris Val
Thanks for the input, very constructive and useful.
- Next message: SaltPeter: "Re: Trouble with non-default constructors"
- Previous message: Stephen Tyndall: "Re: Which Language ??"
- In reply to: Chris Val: "Re: safer stl"
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
Relevant Pages
|
