Re: Checking string allocations (was Re: String literals, ASCII vs UTF-8)

On 03/01/2012 03:42 PM, Lubos Lunak wrote:
> On Wednesday 29 of February 2012, Caolán McNamara wrote:
>   But ok, it's too much to just abort in every case. I think however that
> whether to abort or try to recover does not actually depend on the class
> where the problem occurs, but on where the class is used. I.e. I expect
> nobody will bother (=it's not worthwhile to do) to check for pixmap
> allocation failures and handle them somewhere in drawing code, but may check
> for them in an import filter. And even in the import filter, I think the only
> good reaction is bailing out completely and returning an error, not ignoring
> it silently like in the case I pointed out earlier. So we can split our
> source in two areas:
> - the default, where we don't bother checking and just abort, because it's not
> worthwhile to make the effort
> - special areas, where we expect allocation failures to be more likely (import
> filters, expensive operations in Calc, whatever), there we try to recover
>
>   Which brings me to the following idea: We make rtl_allocateMemory() just
> abort by default. Those special areas get surrounded by setting a flag that
> will change that to throwing an exception, and each of such areas will be
> also inside a try/catch block that'll catch the exception and propagate
> failure of that code in a suitable way.

I don't think that's a good idea.  The semantics you seek are already 
available, by using exceptions, without requiring any additional mechanism.

And when/if we replace the sal C API with a C++ one in LO 4 (where a 
memory allocation function, if we would still need a home-grown one 
anyway, would naturally throw bad_alloc), the issue of consistently 
turning C error return codes into exceptions in the C++ wrappers becomes 
a non-issue.

Stephan