Konstantin,

> Am 22.07.2015 um 13:01 schrieb Konstantin Komissarchik 
> <konstantin.komissarc...@oracle.com>:
> 
> 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
gun...@wagenknecht.org, http://guw.io/







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

Reply via email to