Re: [bug-myserver] [PROPOSAL] Exception management scheme

[Giuseppe Scrivano]

Hi,

exceptions are slow, much slower than a "normal" return but the point is
that they happens very rarely, (otherwise they weren't called
"exceptions").  I think we will have more advantages than disadvantages,
code will resemble more C++ than C and hopefully code readability will
be improved as well.

Actually we just ignore error values and this is bad.  If we were using
directly the return code and errno, we had to check the code after every
syscall used by myserver (and this look like a big task); using
exceptions we can start aggregating code as:

try
  {
  [different things]
  }
catch (exception & e)
 {
   logManager->log ("something bizarre happened %s", e.what ());
   [...]
 }

On the long term though, we would want to be more precise on errors.

Cheers,
Giuseppe



Daniele Perrone <address@hidden> writes:

> Hi All,
>
> I've just a question, what about the performance? It's important to
> manage exceptions in the best way, but we have to keep in mind that
> performance are important in a web server:)
>
> Cheers,
> Daniele
>
> On Sun, Mar 28, 2010 at 12:13 AM, Giuseppe Scrivano <address@hidden> wrote:
>> Hello Lisa,
>>
>> As we already discussed privately, it looks like a good proposal and I
>> agree on everything.
>>
>> Does anyone have comments?
>>
>> Cheers,
>> Giuseppe
>>
>>
>>
>> Lisa Vitolo <address@hidden> writes:
>>
>>> Hi,
>>> I've just taken the task #8646 ("Define an exceptions set") and I want to 
>>> propose and eventually discuss a generic scheme.
>>>
>>> There will be an abstract super class (an interface), let's call it 
>>> MyServerException, with some virtual methods
>>> definitions. This class will be extended by the exception classes, which 
>>> will represent the different errno values.
>>> I was thinking also of making some categories, abstract classes in the 
>>> middle between the superclass and the single
>>> exceptions. They can be useful if a developer wants to catch a whole bunch 
>>> of exceptions regarding the same "area". I think
>>> of: MemoryExceptions (errors like ENOMEM, ENOSPC), SocketExceptions (almost 
>>> every error regarding the socket and connection
>>> management) and FileExceptions.
>>> Little note: some exceptions will need to extend bad_alloc or other 
>>> exceptions from the std library to avoid conflicts (for
>>> example during a dynamic allocation when bad_alloc can be thrown).
>>>
>>> Coming back to the exception, the structure should look like
>>> class Exception : public Category (or MyServerException)
>>> {
>>>   int priority; /* this value describes the level of priority of the 
>>> exception. It cannot be modified and can be useful to
>>> the developer for deciding the next action. */
>>>
>>>   public:
>>>     Exception()
>>>     {
>>>       sets right priority
>>>     }
>>>     int getPriority()
>>>     {
>>>        return priority;
>>>     }
>>>    virtual const char* what() const throw() /* this definition is the 
>>> classic one! */
>>>    {
>>>       return "Error message";
>>>    }
>>>    char **getBacktrace()
>>>    {
>>>      return the backtrace obtained from the glib backtrace_symbols 
>>> function. (http://www.gnu.org/software/libtool/manual/
>>> libc/Backtraces.html)
>>>    }
>>> };
>>>
>>> Eventually, we can wrap this entire system in a macro or function 
>>> CHECK_ERROR that takes the return value of a function and
>>> throws the appropriate exception if necessary.
>>>
>>> Usage example:
>>> try
>>> {
>>>    CHECK_ERROR(bind(...));
>>> } catch ...
>>>
>>> Good night,
>>> Lisa
>>>
>>> --
>>> "The truth can be out there, but lies are inside our heads" -- Terry 
>>> Pratchett
>>
>>
>>