[ https://issues.apache.org/jira/browse/MAPREDUCE-6449?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14904725#comment-14904725 ]
Neelesh Srinivas Salian commented on MAPREDUCE-6449: ---------------------------------------------------- Started on the version 1 of this patch. Questions to confirm my understanding: 1) As mentioned in MAPREDUCE-6439, I agree that there are 3 files in MR that have the catch (YarnRuntimeException e) {} block that needs to be addressed in this JIRA. These files include ~/mapreduce/v2/app/MRAppMaster.java ~/mapreduce/v2/hs/webapp/HsWebServices.java ~/mapreduce/v2/app/webapp/AMWebServices.java The other occurrences are under YARN which I believe is taken in YARN-4021. 2) The objective in this JIRA is to distinguish the calls for the Exception from remote versus local and wrap these under a unified Exception in MR that also helps in backwards compatiibility. 3) I observed that each of the other files in the mapred modules have specific actions in the catch block. Like in TestRecordFactory: catch (YarnRuntimeException e) { e.printStackTrace(); Assert.fail("Failed to crete record"); } So, the idea in this JIRA is to simply map the name of YarnRuntimeException to a single Wrapper for MR Exception? There are instances where the YarnException is expected to be caught: As in TestLocalContainerAllocator which is the local exception catch block. catch (YarnException e) { // YarnException is expected } Please correct/augment this comment to help confirm my understanding. Thank you. > MR Code should not throw and catch YarnRuntimeException to communicate > internal exceptions > ------------------------------------------------------------------------------------------ > > Key: MAPREDUCE-6449 > URL: https://issues.apache.org/jira/browse/MAPREDUCE-6449 > Project: Hadoop Map/Reduce > Issue Type: Bug > Reporter: Anubhav Dhoot > Assignee: Neelesh Srinivas Salian > > In discussion of MAPREDUCE-6439 we discussed how throwing and catching > YarnRuntimeException in MR code is incorrect and we should instead use some > MR specific exception. -- This message was sent by Atlassian JIRA (v6.3.4#6332)