On Mon, 2012-04-02 at 11:59 +0200, Lubos Lunak wrote:
> Could this be please added to the next TSC agenda ?
Yep, pushed & will invite you to the meeting :-)
ATB,
Michael.
--
michael.me...@suse.com <><, Pseudo Engineer, itinerant idiot
___
On Tuesday 20 of March 2012, Lubos Lunak wrote:
> - C++11 deprecates it and instead introduces a noexcept keyword which
> forbids the function to throw anything
>
> I'm not strongly biased either way, but what we have right now are really
> just pretty comments on functions. I think we should eith
On 03/21/2012 03:33 PM, Caolán McNamara wrote:
On Wed, 2012-03-21 at 10:04 +0100, Stephan Bergmann wrote:
it would IMO be nice to nevertheless have information about functions'
exception behaviour around, in a form suitable for mechanical
verification. (For example by disabling GCC's -fno-enfor
On Wed, 2012-03-21 at 10:04 +0100, Stephan Bergmann wrote:
> it would IMO be nice to nevertheless have information about functions'
> exception behaviour around, in a form suitable for mechanical
> verification. (For example by disabling GCC's -fno-enforce-eh-specs
> for --enable-dbgutil builds.)
On Wed, Mar 21, 2012 at 12:33:13PM +0100, Stephan Bergmann wrote:
> But that is completely unrelated to whether you can only throw
> derivations of std::exception or also things like int 5.
Yes, sorry for mixing that in. The problem is can-throw-by-default. If one
would be required to spec what on
On 03/21/2012 12:28 PM, Bjoern Michaelsen wrote:
On Wed, Mar 21, 2012 at 11:54:09AM +0100, Stephan Bergmann wrote:
It does *not* add "another _untyped_ return path," at least not any more so
than it would do if throwable types in C++ were restricted to some specific
subset.
Thats exactly the p
On Wed, Mar 21, 2012 at 11:54:09AM +0100, Stephan Bergmann wrote:
> It does *not* add "another _untyped_ return path," at least not any more so
> than it would do if throwable types in C++ were restricted to some specific
> subset.
Thats exactly the point. In a statically typed environment the def
On 03/21/2012 11:37 AM, Michael Stahl wrote:
for the case where it is a good idea to check exceptions (e.g. Java UNO
bridge, which cannot throw exceptions to the Java side that are not
declared on the interface), a runtime catch-all check should be
sufficient also.
Yep, guards to catch attempts
On 03/21/2012 11:23 AM, Bjoern Michaelsen wrote:
For the most part I would agree here. C++ exceptions are broken by design.
Allowing any kind of object (not even exception) to be thrown by default in a
function adds another _untyped_ return path (as if every function would return
a void* in addit
On 20/03/12 22:50, Lubos Lunak wrote:
>
> Hello,
>
> I've just found out that exception specification on functions in LO have
> been
> just pretty comments, for about 10 years.
>
> Just to make sure what I'm talking about, it's the throw() in e.g. this
>
> void foo( int a, void* b ) throw(
Hi all,
On Tue, Mar 20, 2012 at 10:50:02PM +0100, Lubos Lunak wrote:
> - boost, and pretty much everybody else it seems, do not consider it worth
> the
> hassle of specifying what a function may or may not throw, except for
> flagging a non-inline method as not throwing any exception at all as
On 03/21/2012 08:40 AM, Tor Lillqvist wrote:
I think a large part of our hackers, certainly of new ones, might have
more experience of Java than C++. They might think that C++ is more
like Java, and that the throw clauses are crucial to be exactly right
(for some value of "right"), and then waste
On 03/20/2012 10:50 PM, Lubos Lunak wrote:
I've just found out that exception specification on functions in LO have been
just pretty comments, for about 10 years.
[...]
I found out by compiling LO with Clang, running it and having it crash where
gcc-compiler version had no problem. Stephan
> Opinions on this?
I am in favour of removing the throw specifications. Especially after
reading your link (and what it links to, like
http://www.gotw.ca/publications/mill22.htm ).
I think a large part of our hackers, certainly of new ones, might have
more experience of Java than C++. They migh
Hello,
I've just found out that exception specification on functions in LO have been
just pretty comments, for about 10 years.
Just to make sure what I'm talking about, it's the throw() in e.g. this
void foo( int a, void* b ) throw( css::uno::RuntimeException );
which says what exceptions
15 matches
Mail list logo
