Exceptions in class

[mymailaddressin]

im trying to handling exception in my matriz class. I have no idea how this suppoosed to be

My matriz class its like this

#ifndef Matriz_H
#define Matriz_H

#include <iostream>
#include <iomanip>

using namespace std;

template <typename T> class Matriz ;
template <typename T> std::istream& operator >> ( std::istream &is_in,Matriz <T> &M);
template <typename T> std:stream& operator << ( std:stream &os_out, const Matriz <T> &M);

template <typename T>
class Matriz{
friend ostream &operator << <> (ostream &, const Matriz <T> &);
friend istream &operator >> <> (istream &, Matriz <T> &);

public:
Matriz (int = 5, int = 5);
Matriz (const Matriz &);
~Matriz ();

void setSize (int = 5, int = 5);

const Matriz &operator = (const Matriz &);
bool operator == (const Matriz &) const;
Matriz operator * (const Matriz &);
T &operator () (int, int);

private:
int nrows;
int ncols;
T **pntr;
};
#endif

im trying to make the out of range exception in

template <typename T> T &Matriz <T> :: operator()(int rws, int clm) {

// try{
return pntr[rws][clm];
// }
// catch{
// cout << "Out Of Range" << endl;
// }
}
also i would like to know how to handle the invalid type exception

Thanks in advance

 

[Jorgen Grahn]

im trying to handling exception in my matriz class. I have no idea
how this suppoosed to be

My matriz class its like this

What's a Matriz? Maybe I don't need to know, but I'm a bit curious.

....

public:
Matriz (int = 5, int = 5);

Maybe that's legal, but it's much more readable if you supply the
parameter names.

Matriz (const Matriz &);
~Matriz ();

void setSize (int = 5, int = 5); ....

im trying to make the out of range exception in

template <typename T> T &Matriz <T> :: operator()(int rws, int clm) {

// try{
return pntr[rws][clm];
// }
// catch{
// cout << "Out Of Range" << endl;
// }
}

The commented-out code doesn't try to make (throw) an exception, but
handle one generated by evaluating pntr[rws][clm]. And I don't think
that can happen since you're just returning a T&. Even if you
returned a copy of a T, it would probably be unwise to try to handle
any exception caused by the copying /here/; there's simply no sensible
action you could take.

If you instead want to throw when the indexes are out of range, have a

also i would like to know how to handle the invalid type exception

What's that? Type errors should normally happen at compile time.

/Jorgen

 

[mymailaddressin]

I have more questions than answers from you

El lunes, 18 de noviembre de 2013 12:54:45 UTC-6, Jorgen Grahn escribió:

im trying to handling exception in my matriz class. I have no idea

how this suppoosed to be

My matriz class its like this

What's a Matriz? Maybe I don't need to know, but I'm a bit curious.



...

public:

Matriz (int = 5, int = 5);

Maybe that's legal, but it's much more readable if you supply the

parameter names.

Matriz (const Matriz &);

~Matriz ();

void setSize (int = 5, int = 5);
...



im trying to make the out of range exception in

template <typename T> T &Matriz <T> :: operator()(int rws, int clm) {

// try{

return pntr[rws][clm];

// }

// catch{

// cout << "Out Of Range" << endl;

// }

}

The commented-out code doesn't try to make (throw) an exception, but

handle one generated by evaluating pntr[rws][clm]. And I don't think

that can happen since you're just returning a T&. Even if you

returned a copy of a T, it would probably be unwise to try to handle

any exception caused by the copying /here/; there's simply no sensible

action you could take.



If you instead want to throw when the indexes are out of range, have a

look at std::vector<T>::at(). Also, You should probably use the same

exception type as it does (I forget its name).

also i would like to know how to handle the invalid type exception

What's that? Type errors should normally happen at compile time.



/Jorgen



--

// Jorgen Grahn <grahn@ Oo o. . .

\X/ snipabacken.se> O o .

 

[Alf P. Steinbach]

im trying to handling exception in my matriz class. I have no idea how
this suppoosed to be

Some people prefer

if( i > max ) { throw std::runtime_error( "Matrix:perator()" ); }

I generally prefer defining functions called hopefully and fail, and
then writing

hopefully( i <= max )
|| fail( "Matrix:perator()" );

Due to the semantics of the built-in || the arguments to the fail() call
are only evaluated when there is a failure, not in the ordinary course
of the code execution. Thus the two ways of expressing the possible
throwing are equivalent. But I find the hopefully/fail combo to be
easier to recognize visually and much less verbose, and it also
expresses preconditions and postconditions directly, with no negation.

My matriz class its like this

You mean "matrix".

#ifndef Matriz_H
#define Matriz_H

#include <iostream>
#include <iomanip>

In a header file it most often suffices to include <iosfwd>.

That can reduce build times.

using namespace std;

You should NEVER have this in the global namespace in a header.

Consider that the standard library offers names such as `distance`.

The above can easily cause name collisions for e.g. `distance` in code
that uses your header.

template <typename T> class Matriz ;
template <typename T> std::istream& operator >> ( std::istream &is_in,Matriz <T> &M);
template <typename T> std:stream& operator << ( std:stream &os_out, const Matriz <T> &M);

template <typename T>
class Matriz{
friend ostream &operator << <> (ostream &, const Matriz <T> &);
friend istream &operator >> <> (istream &, Matriz <T> &);

I did't think this should compile, but it did.

public:
Matriz (int = 5, int = 5);
Matriz (const Matriz &);
~Matriz ();

void setSize (int = 5, int = 5);

What does setSize mean when the matrix already is larger than specified?

const Matriz &operator = (const Matriz &);

With a suitable state representation the compiler-generated assignment
will suffice.

bool operator == (const Matriz &) const;

OK, although I would have expressed it as a non-member function, due to
the symmetry of an invocation expression.

Matriz operator * (const Matriz &);

Missing a "const".

One pretty competent fellow has disagreed with this view, but I would
rather have operator*= as member function, and provide operator* as a
non-member function implemented in terms of operator*=.

T &operator () (int, int);



private:
int nrows;
int ncols;
T **pntr;

Oh, a double-star programmer.

Replace that representation with just

int nrows;
int ncols;
std::vector<T>

and you get copy construction, copy assignment and proper destruction
for free. Not to mention allocation. And ... so on.

};
#endif

im trying to make the out of range exception in

template <typename T> T &Matriz <T> :: operator()(int rws, int clm) {

// try{
return pntr[rws][clm];
// }
// catch{
// cout << "Out Of Range" << endl;
// }
}
also i would like to know how to handle the invalid type exception

Assuming you change the representation as indicated, you can simply use
the std::vector::at method to automatically get a range exception.

However, there are two important considerations:

* Do you really want an exception, or perhaps rather an assertion?
I define a macro XASSERT for cases like these, which uses `assert` for
a debug build and throws a std::logic_error for release build.

* If you want an exception, for the purpose of higher level code
catching it, then do you want the kind you get from `at`?
No, in this case you rather want a std::runtime_error.


Cheers & hth.,

- Alf

 

[Cholo Lennon]

What's a Matriz? Maybe I don't need to know, but I'm a bit curious.

Matriz is the spanish/portuguese word for Matrix

 

[mymailaddressin]

Yeah Matriz is the spanish word for Matrix

Its good to know you learn about the operators >> and <<

Well
I'm trying to implement is out of range exception in matriz class


El lunes, 18 de noviembre de 2013 13:34:46 UTC-6, Alf P. Steinbach escribió:

im trying to handling exception in my matriz class. I have no idea how

this suppoosed to be

Some people prefer



if( i > max ) { throw std::runtime_error( "Matrix:perator()" ); }



I generally prefer defining functions called hopefully and fail, and

then writing



hopefully( i <= max )

|| fail( "Matrix:perator()" );



Due to the semantics of the built-in || the arguments to the fail() call

are only evaluated when there is a failure, not in the ordinary course

of the code execution. Thus the two ways of expressing the possible

throwing are equivalent. But I find the hopefully/fail combo to be

easier to recognize visually and much less verbose, and it also

expresses preconditions and postconditions directly, with no negation.

My matriz class its like this

You mean "matrix".

#ifndef Matriz_H

#define Matriz_H

#include <iostream>

#include <iomanip>

In a header file it most often suffices to include <iosfwd>.



That can reduce build times.

using namespace std;

You should NEVER have this in the global namespace in a header.



Consider that the standard library offers names such as `distance`.



The above can easily cause name collisions for e.g. `distance` in code

that uses your header.

template <typename T> class Matriz ;

template <typename T> std::istream& operator >> ( std::istream &is_in,Matriz <T> &M);

template <typename T> std:stream& operator << ( std:stream &os_out, const Matriz <T> &M);

template <typename T>

class Matriz{

friend ostream &operator << <> (ostream &, const Matriz <T> &);

friend istream &operator >> <> (istream &, Matriz <T> &);

I did't think this should compile, but it did.



So, happily, I learned something new today also. <g>

public:

Matriz (int = 5, int = 5);

Matriz (const Matriz &);

~Matriz ();

void setSize (int = 5, int = 5);

What does setSize mean when the matrix already is larger than specified?

const Matriz &operator = (const Matriz &);

With a suitable state representation the compiler-generated assignment

will suffice.

bool operator == (const Matriz &) const;

OK, although I would have expressed it as a non-member function, due to

the symmetry of an invocation expression.

Matriz operator * (const Matriz &);

Missing a "const".



One pretty competent fellow has disagreed with this view, but I would

rather have operator*= as member function, and provide operator* as a

non-member function implemented in terms of operator*=.

T &operator () (int, int);








int nrows;

int ncols;

T **pntr;

Oh, a double-star programmer.



Replace that representation with just



int nrows;

int ncols;

std::vector<T>



and you get copy construction, copy assignment and proper destruction

for free. Not to mention allocation. And ... so on.

};


im trying to make the out of range exception in

template <typename T> T &Matriz <T> :: operator()(int rws, int clm) {

// try{

return pntr[rws][clm];

// }

// catch{

// cout << "Out Of Range" << endl;

// }

also i would like to know how to handle the invalid type exception

Assuming you change the representation as indicated, you can simply use

the std::vector::at method to automatically get a range exception.



However, there are two important considerations:



* Do you really want an exception, or perhaps rather an assertion?

I define a macro XASSERT for cases like these, which uses `assert` for

a debug build and throws a std::logic_error for release build.



* If you want an exception, for the purpose of higher level code

catching it, then do you want the kind you get from `at`?

No, in this case you rather want a std::runtime_error.





Cheers & hth.,



- Alf

 

[Öö Tiib]

Some people prefer

if( i > max ) { throw std::runtime_error( "Matrix:perator()" ); }

I generally prefer defining functions called hopefully and fail, and
then writing

hopefully( i <= max )
|| fail( "Matrix:perator()" );

Due to the semantics of the built-in || the arguments to the fail() call
are only evaluated when there is a failure, not in the ordinary course
of the code execution. Thus the two ways of expressing the possible
throwing are equivalent. But I find the hopefully/fail combo to be
easier to recognize visually and much less verbose, and it also
expresses preconditions and postconditions directly, with no negation.

[snip]

Except:

if (hopefully(foo) || fail(bar))
{
// do stuff
}

looks like we should "do stuff" if fail returns true in other words your
coding style demonstrates yet more obfuscation.

Might be obfuscation was introduced when you added redundant "if" (that
the "hopefully" was meant to replace) and brackets?

 

[Öö Tiib]

On 18/11/2013 19:34, Alf P. Steinbach wrote:
On 18.11.2013 19:33, (e-mail address removed) wrote:
im trying to handling exception in my matriz class. I have no
idea how this suppoosed to be

Some people prefer

if( i > max ) { throw
std::runtime_error( "Matrix:perator()" ); }

I generally prefer defining functions called hopefully and fail,
and then writing

hopefully( i <= max )
|| fail( "Matrix:perator()" );

Due to the semantics of the built-in || the arguments to the
fail() call are only evaluated when there is a failure, not in
the ordinary course of the code execution. Thus the two ways of
expressing the possible throwing are equivalent. But I find the
hopefully/fail combo to be easier to recognize visually and much
less verbose, and it also expresses preconditions and
postconditions directly, with no negation.

[snip]

Except:

if (hopefully(foo) || fail(bar))
{
// do stuff
}

looks like we should "do stuff" if fail returns true in other words
your coding style demonstrates yet more obfuscation.

Might be obfuscation was introduced when you added redundant
"if" (that the "hopefully" was meant to replace) and brackets?

Fair point, but the original form is somewhat javascriptish. It is a
matter of taste but I prefer code which is more explicit than that. To
that extent it could be regarded as somewhat obfuscatory, but beauty is
in the eye of the beholder and clearly Alf likes it.

I myself use set of "paranoid programming" macros. Macros do look less
neat, (as macros are capitalized) but that makes them even easier to
visually recognize.

The hopefully() function form itself is quite useful, and a well-known
idiom if it causes the compiler to emit instructions that will cause
branch prediction to favour the expected outcome. But I do not think
that was the suggestion here.

I see it was suggested as a way to indicate failure handling
differently than with ordinary ifs. I think of my macros as
"no much else to do" since otherwise there's no way to instrument
debugging information (file, line number, function's name) to such
problem checking. Debugging is needed since in early stages it is
often not known (even stated opinions will often change) how a
program should react to one or other failure or edge case.