Exception Handling and the Test System

Development related to the GMAT core and GUI

Exception Handling and the Test System

Postby DJCinSB » Fri Nov 26, 2010 7:39 pm

GMAT has an automated test system in the works that keys off of specific strings in the messages generated during a run to detect warnings and errors. In order for this system to work, those strings need to be displayed consistently. The purpose of this topic is to describe an approach for the exception classes that ensures consistency in the error messages.

The test system looks for the strings "**** ERROR ****" and "**** WARNING ****" while it processes output from GMAT. These strings need to appear at the start of the exception message on order to be detected by the test system.

Our exception classes exist in a shallow hierarchy all derived from the BaseException class. The current constructor for the base class has this signature:
Code: Select all
BaseException(const std::string& message = "",
         const std::string &details = "");

Additionally, there is a message enumeration in place in the MessageReceiver code that is used to classify popup messages:
Code: Select all
//namespace Gmat
{
   enum MessageType
   {
      ERROR_ = 10, //loj: cannot have ERROR
      WARNING_,
      INFO_,
      DEBUG_
   };
}

This enumeration defines message types that fit the needs of the test system, but is not used for the exception classes.

We could do a bit of refactoring to move the existing capability into place for the exception classes. To do this, the MessageType addition to the namespace should be moved from MessageReceiver.hpp into gmatdefs.hpp and possibly given an additional entry, GENERAL_ (for general purpose messages). The BaseException class could be given an additional parameter, defaulted to some value (I'll use GENERAL_ here):
Code: Select all
BaseException(const std::string& message = "",
         const std::string &details = "",
         Gmat::MessageType mt = Gmat::GENERAL_);

which sets a new internal member, msgType, to the type of the exception. The method that generates exception messages that are shown to the user would use this parameter to decorate the exception, ensuring consistency in the strings:
Code: Select all
std::string BaseException::GetFullMessage() const
{
   std::string preface = "";

   if (msgType == Gmat::ERROR_)
      preface = "**** ERROR **** ";
   if (msgType == Gmat::WARNING_)
      preface = "**** WARNING **** ";
   return preface + theMessage + theDetails;
}

The existing exception classes would need to be modified to work with the new parameter, but that change could be put in place as needed while we work on the upcoming release, and completed afterwards.

I've prototyped this approach while working on bug 2225 ("No **** ERROR **** text in Targeter validation message"), and it seems to work correctly for the Target command (and, by inference, for the CommandException class) in that context without changing the existing functionality. I'm providing this writeup to solicit feedback before committing that code to the repository.

- Darrel
DJCinSB
 
Posts: 274
Joined: Mon Jun 09, 2008 3:57 pm

Re: Exception Handling and the Test System

Postby dev-wcs » Mon Nov 29, 2010 2:21 pm

This looks like a good approach to me.

Should the default type be Error? I thought we decided to use exceptions mostly for error conditions, but maybe that guideline hasn't really been maintained.
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
Views expressed are my own and
do not necessarily reflect those
of my employer, or anyone else.
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
dev-wcs
 
Posts: 97
Joined: Tue Jun 10, 2008 1:01 pm

Re: Exception Handling and the Test System

Postby DJCinSB » Mon Nov 29, 2010 3:36 pm

dev-wcs wrote:Should the default type be Error? I thought we decided to use exceptions mostly for error conditions, but maybe that guideline hasn't really been maintained.

I thought about doing that, but wanted to avoid (at least in my preliminary tests of the approach) seeing messages that have the string twice (i.e. "**** ERROR **** **** ERROR ****"). It does make sense to me to make that the default, though.

Eventually, we might want to use the other settings and let the user determine through their startup configuration if, for instance, they break on warning or continue.
DJCinSB
 
Posts: 274
Joined: Mon Jun 09, 2008 3:57 pm


Return to Core Development

Who is online

Users browsing this forum: Bing [Bot] and 1 guest

cron