Re: Addin exceptions in SvStream

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.

        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 ? =].

        If so that would means passing a tools::StreamIOException to ~every
method in the project, 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 ;-)

        So - for me, I'd love to not use them to solve this problem.

        ATB,

                Michael.

-- 
michael.meeks@suse.com  <><, Pseudo Engineer, itinerant idiot