Back to index

salome-kernel  6.5.0
Salome Kernel resources for developer

This document describes the development environment for C++ and Python.

Makefiles generation and usage are introduced in another document: "using the %SALOME configuration and building system environment". Development environment is intended here as: trace and debug macros usage; SALOME exceptions usage, in C++ and Python; user CORBA exceptions usage, in C++ and Python, with and without Graphical User Interface; some general purpose services such as singleton, used for CORBA connection and disconnection.

Trace and debug Utilities

During the development process, an execution log is useful to identify problems. This log contains messages, variables values, source files names and line numbers. It is recommended to verify assertions on variables values and if necessary, to stop the execution at debug time, in order to validate all parts of code.

Two modes: debug and release

The goal of debug mode is to check as many features as possible during the early stages of the development process. The purpose of the utilities provided in SALOME is to help the developer to add detailed traces and check variables values, without writing a lot of code.

When the code is assumed to be valid, the release mode optimizes execution, in terms of speed, memory, and display only user level messages.

But, some informations must always be displayed in both modes: especially messages concerning environment or internal errors, with version identification. When an end user is confronted to such a message, he may refer to a configuration documentation or send the message to the people in charge of SALOME installation, or to the development team, following the kind of error.

C++ Macros for trace and debug

SALOME provides C++ macros for trace and debug. These macros are in:


This file must be included in C++ source. Some macros are activated only in debug mode, others are always activated. To activate the debug mode, DEBUG must be defined, which is the case when SALOME Makefiles are generated from configure, without options. When DEBUG is undefined (release mode: configure --disable-debug --enable-production), the debug mode macros are defined empty (they do nothing). So, when switching from debug to release, it is possible (and recommended) to let the macro calls unchanged in the source.

All the macros generate trace messages, stored in a circular buffer pool. A separate thread reads the messages in the buffer pool, and, depending on options given at SALOME start, writes the messages on the standard output, a file, or send them via CORBA, in case of a multi machine configuration.

Three informations are systematically added in front of the information displayed:

Macros defined in debug and release modes

Macros defined only in debug mode


C++ exceptions: class SALOME_Exception


The class SALOME_Exception provides a generic method to send a message, with optional source file name and line number. This class is intended to serve as a base class for all kinds of exceptions SALOME code. All the exceptions derived from SALOME_Exception could be handled in a single catch, in which the message associated to the exception is displayed, or sent to a log file.

The class SALOME_Exception inherits its behavior from the STL class exception.


The header SALOME/src/utils/utils_SALOME_Exception.hxx must be included in the C++ source, when raised or trapped:

#include "utils_SALOME_Exception.hxx"

The SALOME_Exception constructor is:

SALOME_Exception( const char *text,
                  const char *fileName=0, 
                  const unsigned int lineNumber=0 );

The exception is raised like this:

throw SALOME_Exception("my pertinent message");

or like this:

throw SALOME_Exception(LOCALIZED("my pertinent message"));

where LOCALIZED is a macro provided with utils_SALOME_Exception.hxx which gives file name and line number.

The exception is handled like this:

catch (const SALOME_Exception &ex)
  cerr << ex.what() <<endl;

The what() method overrides the one defined in the STL exception class.

CORBA exceptions


The idl SALOME_Exception provides a generic CORBA exception for SALOME, with an attribute that gives an exception type,a message, plus optional source file name and line number.

This idl is intended to serve for all user CORBA exceptions raised in SALOME code, as IDL specification does not support exception inheritance. So, all the user CORBA exceptions from SALOME could be handled in a single catch.

The exception types defined in idl are:

CORBA system and user exceptions already defined in the packages used within SALOME, such as OmniORB exceptions, must be handled separately.


CORBA servant, C++

The CORBA Server header for SALOME_Exception and a macro to throw the exception are provided with the header KERNEL_SRC/src/Utils/Utils_CorbaException.hxx:

The exception is raised with a macro which appends file name and line number:

if (myStudyName.size() == 0)

CORBA Client, GUI Qt C++ (NO MORE AVAILABLE in SALOME 3.x and later)

The CORBA Client header for SALOME_Exception and a Qt function header that displays a message box are provided in:


#include "SALOMEGUI_QtCatchCorbaException.hxx"

A typical exchange with a CORBA Servant will be:

 ... // one ore more CORBA calls

catch (const SALOME::SALOME_Exception & S_ex)

CORBA Client, C++, without GUI

Nothing specific has been provided to the developer yet. See the idl or the Qt function SALOMEGUI_QtCatchCorbaException.hxx to see how to get the information given by the exception object.

Miscellaneous tools



A singleton is an application data which is created and deleted only once at the end of the application process. The C++ compiler allows the user to create a static singleton data before the first executable statement. They are deleted after the last statement execution.

The SINGLETON_ template class deals with dynamic singleton. It is useful for functor objects. For example, an object that connects the application to a system at creation and disconnects the application at deletion.


To create a single instance of a POINT object:

# include "Utils_SINGLETON.hxx"
POINT *ptrPoint=SINGLETON_<POINT>::Instance() ; 
assert(ptrPoint!=NULL) ;

No need to delete ptrPoint. Deletion is achieved automatically at exit. If the user tries to create more than one singleton by using the class method SINGLETON_<TYPE>::Instance(), the pointer is returned with the same value even if this is done in different functions (threads ?):

POINT *p1=SINGLETON_<POINT>::Instance() ;
POINT *p2=SINGLETON_<POINT>::Instance() ; 


Design description

Here are the principles features of the singleton design: