Addin exceptions in SvStream

[Michael Meeks]

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 at suse.com  <><, Pseudo Engineer, itinerant idiot