Thread: Run-time function identification

Maybe?

Code:

#include<iostream>
#include<stdexcept>
#include<cmath>
using namespace std;
class exp_catch: public logic_error{
public:
  exp_catch(double x, double y, const char *s = "Logic error exception thrown!!!"):m_x(x), m_y(y), logic_error(s){}
  void hmean() throw(logic_error);
  void gmean() throw (logic_error);
  void show_val();
private:
  double m_x;
  double m_y;    
  const char *m_lastfn;
};
int main(){
  exp_catch e1(10, -12);
  try{
    e1.hmean();
    e1.gmean();
  }
  catch(logic_error & le){
    cout<<le.what()<<endl;
    e1.show_val();
  }
}
void exp_catch::hmean() throw (logic_error){
  m_lastfn = __PRETTY_FUNCTION__;
  if(m_x == -m_y){
    throw *this;
  }
  double z = (2 * m_x * m_y) /(m_x + m_y);
  cout <<"Harmonic mean is: "<<z<<endl;
}
void exp_catch::gmean() throw(logic_error){
  m_lastfn = __PRETTY_FUNCTION__;
  if (m_x < 0 || m_y < 0){
    throw *this;
  }
  double z = std::sqrt(m_x * m_y);
  cout<<"Geometric mean is: "<< z<<endl;
}
void exp_catch::show_val(){
  cout<<"The input values are: "<<m_x<<" and "<<m_y<<endl;
  cout<<"Occurred in " << m_lastfn << endl;
}


$ g++  foo.cpp
$ ./a.out 
Harmonic mean is: 120
Logic error exception thrown!!!
The input values are: 10 and -12
Occurred in void exp_catch::gmean()

You should have a member in your class that identifies exactly what kind of error occurred. Then from what, you can determine where the error occurred. But really, you shouldn't so much pay attention to where it came from as much as what kind of error it was.

Originally Posted by whiteflags

I thought that's why exceptions were typed.

Not necessarily always. You can use enums and other information bundled in the exception to specify more information. Many libraries tend to group exceptions into different categories and using constants or whatever to give more detailed information.

That seems like really stupid advice, since in the code given the only way to prevent the exception is to pass good arguments... it makes sense you would need to know the offending function call. Every backtrace I've ever seen keeps track of line, file and function name so it is need to know information.

It paves way for abstraction, which is a good thing™. How many functions do you have in your application? Are you going to try to use different error parsing for every function? What if your functions change? What if they're refactored? Besides, many functions can throw many errors.

Backtraces are good, but they're not meant for users. They're meant for developers to help track down the error. That information shouldn't be used by the code to determine where the error came from.

OK ... I'm not asking you to justify specific error handling designs to me. I am already aware that exceptions can be hierarchies, use explanatory constants, etc. What confused me about what you said about not needing to know where the error occurred.

Then from what, you can determine where the error occurred. But really, you shouldn't so much pay attention to where it came from as much as what kind of error it was.

Right, but what information would the string have if we're not supposed to care where the error occurred?

I mean, I don't expect what to be a full backtrace, but I do expect it to have information typical of one - function name, line, file... hopefully it is clear what I am asking because I don't know where you are going with your advice.

I believe we're on the same track. I do believe having information about where the error came from to be useful. But I don't think the code should act on it. It's the developer's job to act on it:

Code:

catch (MyEx ex) // Being lazy
{
    switch (ex.Error) // Determine what kind of error happened and try to recover; or present an error to the user.
    {
        // ...
    }
    Log(ex.Backtrace); // Log the backtrace so the developer can see exactly why the error occurred.
}