[
https://issues.apache.org/jira/browse/HDDS-1365?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16807836#comment-16807836
]
Yiqun Lin edited comment on HDDS-1365 at 4/2/19 3:06 PM:
-
Hi [~sdeka], the error code can be kept since we can do the corresponding
handle logic (e.g. notify SCM corrupted containers) based on these error code
value in the future like following:
{code:java}
KvCheckError error;
switch(error) {
case FILE_LOAD:
// Handler logic1..
break;
case METADATA_PATH_ACCESS
// Handler logic2..
break;
case CHUNKS_PATH_ACCESS
// Handler logic3..
break;
...
default
break;
}
{code}
Based on the current change, the exception is almost swallowed. We only log the
exception message, how can we do the handle logic for different error cases?
Other refactor looks good to me. One nit:
{{assertTrue(corruption == false);}} can be simplified to
{{assertFalse(corruption);}}
was (Author: linyiqun):
Hi [~sdeka], the error code can be kept since we can do the corresponding
handle logic (e.g. notify SCM corrupted containers)according to error code
value in the future like following:
{code:java}
KvCheckError error;
switch(error) {
case FILE_LOAD:
// Handler logic1..
break;
case METADATA_PATH_ACCESS
// Handler logic2..
break;
case CHUNKS_PATH_ACCESS
// Handler logic3..
break;
...
default
break;
}
{code}
Based on the current change, the exception is almost swallowed. We only log the
exception message, how can we do the handle logic for different error cases?
Other refactor looks good to me. One nit:
{{assertTrue(corruption == false);}} can be simplified to
{{assertFalse(corruption);}}
> Fix error handling in KeyValueContainerCheck
>
>
> Key: HDDS-1365
> URL: https://issues.apache.org/jira/browse/HDDS-1365
> Project: Hadoop Distributed Data Store
> Issue Type: Sub-task
> Components: Ozone Datanode
>Reporter: Supratim Deka
>Assignee: Supratim Deka
>Priority: Major
> Attachments: HDDS-1365.000.patch
>
>
> Error handling and propagation in KeyValueContainerCheck needs to be based on
> throwing IOException instead of passing an error code to the calling function.
> HDDS-1163 implemented the basic framework using a mix of error code return
> and exception handling. There is added complexity because exceptions deep
> inside the call chain are being caught and translated to error code return
> values. The goal is to change all error handling in this class to use
> Exceptions.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
-
To unsubscribe, e-mail: hdfs-issues-unsubscr...@hadoop.apache.org
For additional commands, e-mail: hdfs-issues-h...@hadoop.apache.org
