Addin exceptions in SvStream

Marc-André Laverdière marcandre.laverdiere at
Thu Dec 13 03:10:34 PST 2012

That's the problem... what we don't know can be hurting us big time.
And since the tests are not very thorough, I can't have a good
confidence that things are not broken.

So, either we finish this patch and hope people will pick up those
cases along the way - a risky proposal but it has the advantage of
immunizing pretty much every filter for 'cheap'.

Otherwise, I suggest that we go for a SvStream wrapper that throws
exceptions - no changes to SvStream. It can be used wherever wanted,
so that's a lot of engineering effort to bolt that in place - but less
work than just putting stream->good() checks everywhere.
"Perseverance must finish its work so that you may be mature and complete,
not lacking anything." -James 1:4

On Thu, Dec 13, 2012 at 4:40 AM, Michael Meeks <michael.meeks at> wrote:
> Hi Marc,
> On Thu, 2012-12-13 at 02:09 -0500, Marc-André Laverdière wrote:
>> I feel that this behavior of SvStream not to change the parameter in
>> case of a broken stream should be changed. I am not sure why that is
>> there.
>         Well - it is -thought- (but hard to prove) that this behaviour is
> relied on by the code in a number of places:
>         sal_uInt16 nFallbackStyleFoo = 0xffff;
>         nStream >> nFallbackStyleFoo;
>         And that nil'ing it - though attractive -might- then break things.
> Clever ideas to find and fix those few cases appreciated - but in
> general combining that with re-working to use explicit read functions
> seems like a good (albeit time-consuming) idea.
>         Of course, it'd be possible to imagine a boolean on the stream to
> return defined data in these cases - but that's a bit sick IMHO ;-) if
> we have to audit the code and test it, why not clean it to use (much
> safer) readInt16(); style methods :-)
>         HTH,
>                 Michael.
> --
> michael.meeks at  <><, Pseudo Engineer, itinerant idiot

More information about the LibreOffice mailing list