Addin exceptions in SvStream
Stephan Bergmann
sbergman at redhat.com
Tue Dec 11 06:57:25 PST 2012
On 12/11/2012 11:11 AM, Michael Meeks wrote:
> On Tue, 2012-12-11 at 09:39 +0100, Stephan Bergmann wrote:
>> On 12/10/2012 10:41 PM, Michael Meeks wrote:
>>> On Mon, 2012-12-10 at 10:27 -0500, Marc-André Laverdière wrote:
>>>> I am doing some proactive hardening of the image filters these days,
>>>> and I have to say that there is a lot of code like this:
> ...
>>> meh = stream.ReadInt32();
>>> Where we default to zero for end-of stream and bad streams - rather
> ...
>> Getting rid of >> overloads and introducing (optional) exceptions are
>> orthogonal.
>
> Certainly - but if the aim of (optional?) exceptions is to harden the
> code against bad content - then IMHO it is far better to write explicit
> code to handle the few cases where we can do anything meaningful. Better
> to do that by treating 0's as a default default to read when there is no
> data - and move on.
I personally know little about code that uses SvStream to actually read
files, so can't say much on that topic.
> Then again - I still don't understand your concern elsewhere about
> exception specifications; IIRC you want -all- methods that call any
> methods that might throw a given exception to declare that they might
> throw that exception - [ is that right, I'm still staggered by the
> idea ? =].
No. I expect that functions document the conditions under which they
throw exceptions that are designed to be treated programmatically. (So
that client code can meaningfully respond to them.)
> If so that would means passing a tools::StreamIOException to ~every
> method in the project,
Hu? The OP was about /optionally/ switching on exceptions from
SvStream, for such client code that will take care to catch and handle
those exceptions.
Is your misconception that if there is, say, a function f(int x) that is
documented to throw E iff x==0 and there is a function g(int y) { f(y);
} that has a documented precondition that y>0, that g would nevertheless
be required to carry a dynamic exception specification of throw (E)?
> writing that explicitly in the signatures, and/or
> having a bazillion try { } catch (StreamIOException) { throw
> uno::RuntimeException(); } monsters at each UNO interface ?
>
> All I know is that exceptions appear to produce endemic bloat in the
> form of big unwind tables, tend to get thrown and caught a lot during
> common (particularly UNO) operations - making debugging of the 'real'
> exceptions unpleasantly difficult, and (AFAICS) are no better a way of
> solving the well-known security problems around streams than returning
> defined data for out-of-bound conditions ;-)
Exceptions are certainly no silver bullet (semantically they are
~equivalent to encoding exception information in function return values
and explicitly handling those return values accordingly, so the "endemic
bloat" claim meets skepticism), but "returning defined data for
out-of-bound conditions" isn't necessarily either (whatever "the
well-known security problems around streams" would actually be).
Stephan
More information about the LibreOffice
mailing list