Returning undeclared ..

I have an overloaded operator that returns a Matrix,

when the Matrix can't do the computation, i need it to output text instead... is this possible?

I have it outputting text, but it is processed above the text where I need it. Example output:

Working:
0 23 23
43 0 2
1 1 3

Not working: INVALID MATRIX

as you can see from the "Not working" it doesn't display a matrix, only the text INVALID MATRIX
It sounds like you need to throw an exception in these exceptional circumstances (not being able to do a calculation).
thats what i was thinking... haven't used those before, time to do some research
how do i incorporate that?

I need some help this is confusing me...

1
2
3
4
5
6
7
8
9
10
Test Test::somefunction(int i, int j)
{
  if( i != j  )
    throw exception here
  else {
   //do some stuff
  return something
  }

}
Something like:
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
#include "Matrix.hpp"
#include <stdexcept>

Matrix f(const Matrix &a, const Matrix &b)
{
    if (!check(a, b))
        throw std::runtime_error("Cannot do f(a, b)");
   return Matrix::f(a, b);
}

int main()
{
    Matrix a, b, c:
    std::cin >> a >> b;
    try
    {
        c = f(a, b);
    }
    catch (const std::exception &e)
    {
        std::clog << e.what() << std:endl;
        return 1;
    }
    return 0;
}

A good programm is an exception free one, no exception!
I agree, and my program has no errors but when you need to because your teacher insists on it , you must :)
I'm not a fan of exceptions, so I try to find alternatives. Which alternative is possible depends on the context.

How is the matrix returned? If by pointer, then you can simply return a nullptr. If by value or reference, that's not an option. Checking for nullptrs is easy and should be done anyway in most cases.

Personally, I prefer using 'assert': it checks whether a condition is true, and if not throws an error and quits. It's nice because they are automatically ignored in release builds and they are very easy to include. However, it's not useful if something else than program logic can cause these 'errors' (e.g. user input), because you can't simply verify everything at compile time.

Lastly, making sure the conditions are good before calling a function is often easier than during, because the function itself might be stuck with a certain return type or flow restriction.

As an example, think of a Matrix Squaring function. Squaring requires a matrix to be NxN, which is easy to check:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
// By nullptr 
Matrix* sqMat(Matrix& mat) {
  Matrix *squared;
  if (mat.rows != mat.cols) squared = nullptr;
  else squared = new Matrix(mat * mat);
  return squared;
} 
// Using assert to verify
#include <cassert>
Matrix sqMat(Matrix& mat) {
  assert(mat.rows == mat.cols); // Quits and errors if unequal.
  return mat*mat;
}
// Pre-verification
if (matrix.cols == matrix.rows) squared = sqMat(matrix);
Last edited on
As already suggested you can throw. Alternatively you can return a sentinel matrix, some matrix that you use as a sentinel value to report an error has occurred. That is if it doesn't matter where the text printing comes from. If your teacher says that it must come from within the overloaded operator your only choice is to throw.

What you do is if a calculation can be done you return this 'INVALID MATRIX'. Then before you display anything check to see that the matrix returned is not the invalid matrix, if it isn't display the matrix otherwise display INVALID MATRIX.
therockon7throw A good programm is an exception free one, no exception!
Don't be silly.

clanmjc Alternatively you can return a sentinel matrix
. That only works if you're the immediate caller of the failed calculation, so you must handle the error there. If you use an exception, you can handle the error at a higher level where it may be more suitably dealt with.

The truth of the matter is it is an exceptional circumstance and may be caused at runtime.
That only works if you're the immediate caller of the failed calculation, so you must handle the error there. If you use an exception, you can handle the error at a higher level where it may be more suitably dealt with.
Agreed. Just giving an alternative if exceptions aren't allowed or haven't been covered yet.
Topic archived. No new replies allowed.