Quote:

Original post by paulecoyote I know that this article is a bit old and thread a bit stale and necro'ed, but I was wondering if anyone had an example of an exception inherited from the stl exception - and what advantages doing that would have from just using your own exception class.

Quote:

Original post by DigitalDelusion Quote: Original post by paulecoyote I know that this article is a bit old and thread a bit stale and necro'ed, but I was wondering if anyone had an example of an exception inherited from the stl exception - and what advantages doing that would have from just using your own exception class. It's all about granularity I commonly inherit from the standard exceptions it gives clients a choice if they desire and need the granularity that my library exceptions offer they have it and if they choose to ignore it they won't get caught in uncaught exception hell as long as they handle standard exceptions correctly. I would actually say it's advicable to *always* inherit from the appropriate stdandar exception and that exceptions to that should be rare.

struct ExceptionWhosNameTellMeWhatWentNuts : public std::runtime_error
{
  ExceptionWhosNameTellMeWhatWentNuts(): std::runtime_error( "something went b0rked during runtime"){}
};

class ExceptionThatHasSomethingIntrestingToSay : public std::exception
{
public:
  ExceptionThatHasSomethingIntrestingToSay(){}
  const char *what() const 
  {
  //create a cool error string
    return my_cool_error_string;
  }
};

Quote:

Original post by paulecoyote You don't need to mess with the operators? What if your exception defined more things (like some kind of stack trace) - how would you invoke the base operator to make sure the private stuff in the base exception is copied as well as your stuff? Is it any different then how you would do that for your own hierachy that did not involve the stl?