[
https://issues.apache.org/jira/browse/PIG-1611?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12974683#action_12974683
]
Alan Gates commented on PIG-1611:
---------------------------------
One concern I have is that this approach of separate enums for each exception
type will lead to a *lot* of duplicated code. Every enum will have to have the
same members and constructors. The methods will be 75% identical, only
getErrorMessage() will vary from enum to enum. I see the trade off here
between this and everyone trying to update the same file with new errors. But
given the choice between the two I'd take the merge issues. They could be
mitigated by carefully sectioning the file by error types, so conflicts would
only happen when developers added error messages of the same type at the same
time. I'm curious which approach others would favor here.
Also, I wonder if there's a way to preserve your approach without the code
duplication. Given the frustrating constraints of Java's enum implementation I
can't think of any, but maybe there is one.
Another comment is I think we should add a fourth field to the enums,
suggestedAction. This would be a string that suggests how to remedy the
situation. Once this is in place a tool could be written to go through the
code and find all the error messages, error numbers, and suggested actions.
This could then be used in the documentation. I'm not suggesting that this
tool should be part of this patch but we can lay the groundwork for it.
bq. Existing exception constructors that use error code number are being
deprecated, so that developers use the new constructors that use. This patch
will not change current code that is already using old constructors.
Why not change existing code? Is the change disruptive? This will leave us in
a strange state with half of our error codes driven from a wiki page and half
from enums. It will be hard for developers unfamiliar with an area of code to
know how to add error messages in that code.
> use enums for error code
> ------------------------
>
> Key: PIG-1611
> URL: https://issues.apache.org/jira/browse/PIG-1611
> Project: Pig
> Issue Type: Sub-task
> Reporter: Thejas M Nair
> Fix For: 0.9.0
>
> Attachments: PIG-1611.1.patch
>
>
> Pig code is using integer constants for error code, and the value of the
> error code is reserved using
> http://wiki.apache.org/pig/PigErrorHandlingFunctionalSpecification .
> This process is cumbersome and error prone.
> It will be better to use enum values instead. The enum value can contain the
> error message and encapsulate the error code.
> For example -
> {code}
> Replace
> throw new SchemaMergeException("Error in merging schema", 2124,
> PigException.BUG);
> with
> throw new SchemaMergeException(SCHEMA_MERGE_EX, PigException.BUG);
> {code}
> Where SCHEMA_MERGE_EX belongs to a error codes enum. We can use the ordinal
> value of the enum and an offset to determine the error code.
> The error code will be passed through the constructor of the enum.
> {code}
> SCHEMA_MERGE_EX("Error in merging schema");
> {code}
> For documentation, the error code and error messages can be dumped using code
> that uses the enum error code class.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
