Rietveld Code Review Tool
Help | Bug tracker | Discussion group | Source code

Issue 6032593782833152: Issue 1173 - proposal for entry point (Closed)

Created:
Jan. 13, 2015, 11:40 a.m. by sergei
Modified:
Feb. 24, 2015, 4:28 p.m.
Reviewers:
Eric, Oleksandr
CC:
Felix Dahlke
Visibility:
Public.

Patch Set 1 #

Patch Set 2 : base on current tip #

Unified diffs Side-by-side diffs Delta from patch set Stats (+277 lines, -235 lines) Patch
M src/plugin/PluginClass.cpp View 1 6 chunks +202 lines, -201 lines 0 comments Download
M src/plugin/PluginUtil.h View 1 1 chunk +23 lines, -17 lines 0 comments Download
M src/plugin/PluginUtil.cpp View 1 2 chunks +52 lines, -17 lines 0 comments Download

Messages

Total messages: 16
sergei
Jan. 29, 2015, 1:35 p.m. (2015-01-29 13:35:45 UTC) #1
Eric
I am completely against using this approach _at the present time_. This is premature optimization ...
Feb. 2, 2015, 1:25 p.m. (2015-02-02 13:25:22 UTC) #2
Oleksandr
I like this approach. If we are going to do this (for which I am ...
Feb. 4, 2015, 10:14 a.m. (2015-02-04 10:14:26 UTC) #3
sergei
On 2015/02/02 13:25:22, Eric wrote: > I am completely against using this approach _at the ...
Feb. 4, 2015, 11:31 a.m. (2015-02-04 11:31:10 UTC) #4
Eric
On 2015/02/04 10:14:26, Oleksandr wrote: > I like this approach. If we are going to ...
Feb. 4, 2015, 12:50 p.m. (2015-02-04 12:50:35 UTC) #5
Eric
On 2015/02/04 11:31:10, sergei wrote: > I don't think it's premature optimization because it already ...
Feb. 4, 2015, 1:06 p.m. (2015-02-04 13:06:43 UTC) #6
sergei
On 2015/02/04 12:50:35, Eric wrote: > However, if we want to use RAII consistently, we ...
Feb. 4, 2015, 1:08 p.m. (2015-02-04 13:08:21 UTC) #7
sergei
Sorry, accidentally sent incomplete message.
Feb. 4, 2015, 1:09 p.m. (2015-02-04 13:09:13 UTC) #8
sergei
On 2015/02/04 12:50:35, Eric wrote: > However, if we want to use RAII consistently, we ...
Feb. 4, 2015, 1:30 p.m. (2015-02-04 13:30:14 UTC) #9
Eric
The central question here is who has the burden of proof about whether this proposal ...
Feb. 4, 2015, 1:32 p.m. (2015-02-04 13:32:56 UTC) #10
sergei
I can say, that it's good at the present time. Because the trouble is already ...
Feb. 4, 2015, 1:47 p.m. (2015-02-04 13:47:21 UTC) #11
Eric
On 2015/02/04 13:30:14, sergei wrote: > Could you provide the example when we need it? ...
Feb. 4, 2015, 2:05 p.m. (2015-02-04 14:05:01 UTC) #12
Eric
On 2015/02/04 13:47:21, sergei wrote: > even if we decide to completely change it in ...
Feb. 4, 2015, 2:13 p.m. (2015-02-04 14:13:03 UTC) #13
Oleksandr
I like the concept, but: 1. I agree that try [] catch (...) {} is ...
Feb. 24, 2015, 8:40 a.m. (2015-02-24 08:40:56 UTC) #14
sergei
On 2015/02/24 08:40:56, Oleksandr wrote: > I like the concept, but: > > 1. I ...
Feb. 24, 2015, 8:54 a.m. (2015-02-24 08:54:31 UTC) #15
Eric
Feb. 24, 2015, 4:28 p.m. (2015-02-24 16:28:22 UTC) #16
On 2015/02/24 08:40:56, Oleksandr wrote:
> 3. I don't think we need try-catch blocks in *every* entry point. I really
don't
> think having that in default QueryInterface implementation will do anything
else
> then decrease readability.

Indeed the new implementation of CPluginUserSettings::QueryInterface does not
use try-catch because there's no statement that can throw within it. We don't
have 'noexcept' in our currently compiler, so instead there's a comment on the
one statement that looks like it _might_ throw. The result we want is to
eliminate exceptions from propagating out of entry points. 'try'-'catch' does
this, as does 'noexcept'.

(Aside: 'noexcept' is not in VS 2013, but it is in VS 2015 Preview. See
http://blogs.msdn.com/b/vcblog/archive/2014/11/17/c-11-14-17-features-in-vs-2...)

> Maybe we'll decide to
> use something like https://msdn.microsoft.com/en-us/library/ms680634.aspx
after
> all.

Sergei's right; unhandled-exception handlers are fraught with peril. Their best
use is to terminate a program as gracefully as possible, given possible program
corruption. In our case that would mean having a something like a global disable
for everything, including all UI. They can also be usefully used to terminate
individual threads, if you've built the infrastructure for that. 

It's certainly nothing we're ready for yet.

Powered by Google App Engine
This is Rietveld