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

[Daniele Perrone]

On Sun, Mar 28, 2010 at 9:50 PM, Giuseppe Scrivano <address@hidden> wrote:
> Daniele Perrone <address@hidden> writes:
>
>> I agree with you, we need a better exceptions management, I want just
>> to point out that we need to be careful with the performance. It's
>> quite known that the try-catch statement introduce an overhead, in my
>> opinion we should keep in mind two simple principles:
>
> yes, that is true.  I did some tests and I saw a try-catch is much
> slower than an usual return statement; but let's put it in these terms,
> in the worst case it happens only once for every request, and I think it
> is faster than serving the request normally; the fastest response is an
> error message :-)
>
>
>
>> - keep the exception class hieararchy as  simple as possible, imho we
>> should just manage unrecoverable exceptions (errors), and treat
>> recoverable exceptional situations without use the exceptions
>> mechanism, Keeping in mind this, the goal is  just to print an error
>> message, with some information useful for the debug, and stop the
>> execution.
>
> hm... but imagine the code in this situation, you will check for errors
> in two distinct code flows as:
>
> try
> {
>  int err = foo ();
>  if (err < 0)
>    {
>      /* Handle error.  */
>    }
> }
> catch (...)
> {
>  /* Handle exception.  */
> }
>
> isn't it too ugly? :-)

Yeah, it seems ugly, but there could be situations where you don't
need at all the try-catch statement, anyway, I see that this
management I propose makes everything less clear.


>> -  in the exception fall use the try catch statement  as late as
>> possible. This should reduce the overhead over the system.
>
> the cost of this approach is to have less precise error messages and I
> am not sure it has an additional cost, unless you are going to re-throw
> the exception again to the upper level.  Is there any benchmark showing
> how "as late as possible" is a better choice than the "as precise as
> possible" one?

I don't know about any benchmark, ok maybe it's better to keep in mind
more the design, and then see which performance we get.

> Cheers,
> Giuseppe
>