pkuwm opened a new issue #361: Improve WorkflowConfig.fromHelixProperty() URL: https://github.com/apache/helix/issues/361 **Problem**: fromHelixProperty() throws IllegalArgumentException if the HelixProperty is not a WorkflowConfig. https://github.com/apache/helix/blob/1063e7a149360ccd30830a0e5eeb549746720751/helix-core/src/main/java/org/apache/helix/task/WorkflowConfig.java#L318-L324 And getWorkflows() uses the way of catching an exception to check whether or not the property is a WorkflowConfig. https://github.com/apache/helix/blob/1063e7a149360ccd30830a0e5eeb549746720751/helix-core/src/main/java/org/apache/helix/task/TaskDriver.java#L770-L780 **Solutions**: 1. Add `boolean isWorkflowConfig(HelixProperty property)` to check so catch exception is avoided. 2. Use Optional. Implement `Optional<WorkflowConfig> fromHelixProperty(HelixProperty property)` Use Optional like below, which might look more intuitive to me than null/exception. ```java public static Optional<WorkflowConfig> parseWorkflowConfig(HelixProperty property) { Map<String, String> configs = property.getRecord().getSimpleFields(); if (!configs.containsKey(WorkflowConfigProperty.Dag.name())) { return Optional.empty(); } return Optional.of(Builder.fromMap(configs).setWorkflowId(property.getId()).build()); } ``` ```java for (Map.Entry<String, ResourceConfig> resource : resourceConfigMap.entrySet()) { String key = resource.getKey(); ResourceConfig resourceConfig = resource.getValue(); WorkflowConfig.parseWorkflowConfig(resourceConfig) .ifPresent(w -> workflowConfigMap.put(key, x)); } ``` **Previous discussions** in https://github.com/apache/helix/pull/357: 1. https://github.com/apache/helix/pull/357#issuecomment-514104602 narendly : As for parseWorkflow - I think it will be cleaner if we could have something like isWorkflowConfig() instead that returns T/F, and based on the result, include it here or not. This way, we do not return null (a code smell), and there are other places in the codebase where we could re-use isWorkflowConfig. I don't think using Optional just for the sake of removing null is appropriate. I wouldn't think it would help with performance either. You could call isWorkflowConfig and parse if it is true, and skip if false, thereby doing minimal amount of parsing needed overall. I think Optional would be beneficial if you want to have fluid chained-calls (similar to functional programming). Here, it is possible to avoid optionality/returning null by checking for the presence of a field. So using Optional is not necessary because you do not need to introduce null in the first place. It would also incur performance/memory overhead. -Hunter Optional is a wrapper for its underlying objects, so it uses more memory and adds the work of boxing/unboxing. I am not claiming that this is significant, but it is a cost we do not have to incur. 2. https://github.com/apache/helix/pull/357#discussion_r306578828 i3wangyi: I'm in full support of using Optional.empty() instead of null. There're numerous articles on the internet saying NPE is a million-dollar mistake, the creation of Optional is just for solving the problem and the wrapper always reminds the developer the possibility of the object being empty. One can search for numerous supports online while the overhead of the optional object itself is simply negligible Welcome to discuss...
---------------------------------------------------------------- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: [email protected] With regards, Apache Git Services
