How does Armadillo library handle error?

Question

Just started on Armadillo library. Through out the documentation and FAQ, I didn't find any reference on how does Armadillo handle errors. For example, how should I know whether "mat A(1e10, 1e10)" is successful or not?

Answer 1

Reading relevant documentation is recommended before asking questions on Stackoverflow.

Examples from Armadillo's documentation :

For R = chol(X) and chol(R, X) functions: if the decomposition fails, R is reset and chol(X) throws a std::runtime_error exception, while chol(R,X) returns a bool set to false .

For the eig_sym(X) and inv(X) functions: if X is not square, a std::logic_error exception is thrown.

For operators like + , a std::logic_error exception is thrown if incompatible object sizes are used.

For element access like A(i,j) , a std::logic_error exception is thrown if the requested element is out of bounds.

etc etc.

The source code for Armadillo is also available, so you can directly look at it and see what it does.

Answer 2

The error handling mechanism of Armadillo is not clear from its documentation. By email communication with the author Sanderson, it's figured out that the error handling mechanism of Armadillo is actually a mixture of C++ std exception and C-style return value. However, the information of what exception will be thrown is still incomplete in the documentation.

For example, to define a matrix, I'll suggest not using "mat X(M, N)" because there is no error handling. The safe way is like this (C-style):

  mat X;
  try{
      X.set_size(M, N);
  } catch (...) {
      printf("memory allocation failed\n");
      return -1;
  }

Note that when memory allocation error occurs, exception "std::logic_error" or "std::bad_alloc" will be thrown (see the comment below by mtall), this is not put in the documentation. When return, use "X.reset()" to release the data memory.

And @mtall: I suggest a less harsh attitude to newbies of a specific field is better for the community health. Force others to read incomplete documentations is not a constructive opinion.In fact, most good open source projects come with documentations not so good, that's why we should help make them more clear and user-friendly.