[
https://issues.apache.org/jira/browse/CASSANDRA-15225?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16897920#comment-16897920
]
Benedict edited comment on CASSANDRA-15225 at 8/1/19 9:36 AM:
--------------------------------------------------------------
{quote}2) Log statement has only one '{}'. I don't think it will print
exception. I prefer caller to handle the logging part.
{quote}
This (the way [~Override] has it) is the correct way to print exceptions;
otherwise only their {{toString()}} method is invoked.
{quote}1) Insteasd of modifying already thrown exception, better to create new
exception and call _newException_.addSuppressed. When the caller calls
_newException_.getSuppressed, accurate list exceptions are returned.
{quote}
I don't think it is correct to have add exceptions with {{addSuppressed}}.
It _is_ the case that often a new exception is created in any place exceptions
are caught, so that the re-throwing method is captured in the trace, however
you would always want a {{cause}} in preference to adding a member of
{{getSuppressed}}.
However, I don't think this anyway always adds value. If I were personally
writing it, I would likely have done it the way [~Override] has done. There's
an alternative, which is to create a new exception whose {{cause}} is the first
caught exception, and to {{addSuppressed}} any remaining exceptions to this new
exception. But I think it's preferable to rethrow the original exception here,
to avoid polluting the printed stack trace, and minimise the risk that
"helpful" tools truncate some of this trace
[~Override]: LGTM, I will merge it alongside your other patch and some others I
will be reviewing hopefully today or tomorrow - unless you want to make any
changes in light of [~n.v.harikrishna]'s feedback?
was (Author: benedict):
{quote}2) Log statement has only one '{}'. I don't think it will print
exception. I prefer caller to handle the logging part.
{quote}
This (the way [~Override] has it) is the correct way to print exceptions;
otherwise only their {{toString()}} method is invoked.
{quote}1) Insteasd of modifying already thrown exception, better to create new
exception and call _newException_.addSuppressed. When the caller calls
_newException_.getSuppressed, accurate list exceptions are returned.
{quote}
I don't think it is correct to have add exceptions with {{addSuppressed}}.
It _is_ the case that often a new exception is created in any place exceptions
are caught, so that the re-throwing method is captured in the trace, however
you would always want a {{cause}} in preference to adding a member of
{{getSuppressed}}.
However, I don't think this anyway always adds value. If I were personally
writing it, I would likely have done it the way [~Override] has done. There's
an alternative, which is to create a new exception whose {{cause}} is the first
caught exception, and to {{addSuppressed}} any remaining exceptions to this new
exception. But I think it's preferable to rethrow the original exception here,
to avoid polluting the printed stack trace, and minimise the risk that
"helpful" tools truncate some of this trace
[~Override]: LGTM, I will merge it alongside your other patch and some others I
will be reviewing hopefully today or tomorrow.
> FileUtils.close() does not handle non-IOException
> -------------------------------------------------
>
> Key: CASSANDRA-15225
> URL: https://issues.apache.org/jira/browse/CASSANDRA-15225
> Project: Cassandra
> Issue Type: Bug
> Components: Local/SSTable
> Reporter: Benedict
> Assignee: Liudmila Kornilova
> Priority: Normal
> Labels: pull-request-available
> Fix For: 3.0.x, 3.11.x, 4.0.x
>
> Time Spent: 10m
> Remaining Estimate: 0h
>
> This can lead to {{close}} not being invoked on remaining items
--
This message was sent by Atlassian JIRA
(v7.6.14#76016)
---------------------------------------------------------------------
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
