It sounds like the consensus is: don’t change [the current questionable uses of
getMessage] unless willing go a step further and provide a detailed,
informative message, which may include the exception’s toString.
Thanks.
-Owen
> On May 28, 2019, at 3:32 PM, Nabarun Nag wrote:
>
> Looking at
Looking at the ticket, it looks like it is an improvement request for some
additional information for the end user, can we just do what Kirk and Bruce
suggested. Add some logs to explain what happened. In my opinion, an end
user will be more happy to get some detail information rather than an
This example came from https://issues.apache.org/jira/browse/GEODE-6796 in
which the submitter assumed that Geode was deliberately emitting a
poorly-worded and confusing error message.
@abaker It sounds like your recommendation for this particular ticket would be
to resolve as ’Not A Bug’, is
I favor providing a detailed log message that includes the Throwable as an
argument.
I have seen code like the following in Geode:
} catch (Exception exception) {
logger.error(exception.getMessage());
}
...but I consider that to be a naive anti-pattern for informing the user
that a problem
In some ways I agree with Owen - it's always better to have more
information about a problem. I can recall seeing blank error messages
or "null" on many occasions.
In other ways I agree with Dan and Anthony that this needs to not be a
global search, but I think that's mostly because our
In the example you provided, I don’t agree that adding the exception class name
creates a better user experience.
Anthony
> On May 25, 2019, at 6:39 PM, Owen Nichols wrote:
>
> Here’s an example of a message that was logged before Jack’s change:
>
> l192.168.99.1: nodename nor servname
Here’s an example of a message that was logged before Jack’s change:
l192.168.99.1: nodename nor servname provided, or not known
Here’s what it will look like now with .toString() instead of .getMessage():
java.net.UnknownHostException: l192.168.99.1: nodename nor servname provided,
or not
I think the right thing to do in those 100+ cases may be different in each
case, a blanket search and replace might not be the best idea.
-Dan
On Fri, May 24, 2019 at 3:05 PM Jinmei Liao wrote:
> does exception.toString() print out the entire stack trace? If so, I don't
> think we should use
does exception.toString() print out the entire stack trace? If so, I don't
think we should use that to replace exception.getMessage().
On Fri, May 24, 2019 at 1:18 PM Jack Weissburg
wrote:
> Hi All,
>
> Owen and I investigated a strange error message caused because Geode
> previously handled an
Hi All,
Owen and I investigated a strange error message caused because Geode
previously handled an error exception with exception.getMessage() instead of
exception.toString().
The issue is that the exception message from exception.getMessage() could
be unhelpful or empty. Instead, we should
10 matches
Mail list logo
