Skip to main content

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
Re: [cross-project-issues-dev] Error reporter and third-party code

> > Stack frames should not be considered sensitive just because they are
from
> > a non-OSS code base. Users post stack traces with commercial code
references
> > in forums all the time. 
> 
> Just because they "can" doesn't imply the are allowed to. There are all
sorts
> of liability questions in here which I can understand as a reason to hide
those.
> I think there is no other option. For most commercial code, the user can
not
> simply allow disclosing such information but a vendor would have to
approve.

As long as we make it an explicit user choice whether convey this
information to eclipse.org, I don't see how it's any different from user
making an explicit choice to convey this information to say stackoverflow.
The burden is on the user to comply with whatever policy or license
obligations might bind them.

How about this system:

1. The top-level package names are extracted from the stack trace.
2. The list is checked against an authorized list, which starts out
populated with OSS namespaces.
3. If entries are found that aren't on the authorized list, the user gets a
prompt like the following:

"An error was detected that includes stack frames with the following
namespaces that you have not yet authorized for reporting to Eclipse
Foundation."

[list of namespaces]

[Authorize] [Authorize Once] [Do Not Report]

> Looking at the stack trace, I read it as some Sapphire code is
initializing a data
> service which is implemented/provided by an adopter. That adopter calls
some WTP code
> which fails. From a Sapphire perspective it shouldn't matter if it's a WTP
issue, 
> i.e. it's the adopter's code which is failing. This should be handled in a
way that
> an adopter realizes it. For example, Sapphire should catch the root
exception and
> wrap it into a Sapphire specific error message which is then either
presented to
> the user or logged to a log file. From an Eclipse.org error handler
perspective,
> this error message should probably then be marked as "log message". It
really
> isn't Sapphires fault here.

My goal is not to remove blame from Sapphire, but to improve the quality
across the Eclipse ecosystem. As such, the proposed strategy doesn't help.

My bottom line... Censored stack traces are useless. At the minimum,
anything that would be censored should not be reported. Ideally, we should
have a better system in place that avoids the need to censor so that we can
help adopters improve their code and let them help us by exposing errors
that are only evident in adopter scenarios.

Thanks,

- Konstantin



-----Original Message-----
From: cross-project-issues-dev-bounces@xxxxxxxxxxx
[mailto:cross-project-issues-dev-bounces@xxxxxxxxxxx] On Behalf Of Gunnar
Wagenknecht
Sent: Thursday, July 23, 2015 9:29 AM
To: Cross project issues
Subject: Re: [cross-project-issues-dev] Error reporter and third-party code

Konstantin,

> Am 22.07.2015 um 13:01 schrieb Konstantin Komissarchik
<konstantin.komissarchik@xxxxxxxxxx>:
> 
> Stack frames should not be considered sensitive just because they are from
a non-OSS code base. Users post stack traces with commercial code references
in forums all the time. 

Just because they "can" doesn't imply the are allowed to. There are all
sorts of liability questions in here which I can understand as a reason to
hide those. I think there is no other option. For most commercial code, the
user can not simply allow disclosing such information but a vendor would
have to approve.

Anyway, I have a different view on your particular topic, which might be a
possible approach for other adopters.

Looking at the stack trace, I read it as some Sapphire code is initializing
a data service which is implemented/provided by an adopter. That adopter
calls some WTP code which fails. From a Sapphire perspective it shouldn't
matter if it's a WTP issue, i.e. it's the adopter's code which is failing.
This should be handled in a way that an adopter realizes it. For example,
Sapphire should catch the root exception and wrap it into a Sapphire
specific error message which is then either presented to the user or logged
to a log file. From an Eclipse.org error handler perspective, this error
message should probably then be marked as "log message". It really isn't
Sapphires fault here.

BTW, the NPE in WTP is bad, though. But we simply can't now if it's a bug in
WTP or if the adopter failed to initialize/setup some expected variables.
But it should be the adopter investigating it.

-Gunnar


-- 
Gunnar Wagenknecht
gunnar@xxxxxxxxxxxxxxx, http://guw.io/







_______________________________________________
cross-project-issues-dev mailing list
cross-project-issues-dev@xxxxxxxxxxx
To change your delivery options, retrieve your password, or unsubscribe from
this list, visit
https://dev.eclipse.org/mailman/listinfo/cross-project-issues-dev



Back to the top