Re: Addin exceptions in SvStream

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