[
https://issues.apache.org/jira/browse/BEAM-5638?focusedWorklogId=201340&page=com.atlassian.jira.plugin.system.issuetabpanels:worklog-tabpanel#worklog-201340
]
ASF GitHub Bot logged work on BEAM-5638:
----------------------------------------
Author: ASF GitHub Bot
Created on: 20/Feb/19 14:43
Start Date: 20/Feb/19 14:43
Worklog Time Spent: 10m
Work Description: jklukas commented on issue #7736: [BEAM-5638] Exception
handling for Java MapElements and FlatMapElements
URL: https://github.com/apache/beam/pull/7736#issuecomment-465605413
I've pushed two new commits to address @reuvenlax's points:
- I factored out the DoFn to a nested class. I didn't make it a static class
since it shares so much state with FlatMapWithExceptions, including delegating
`populateDisplayData`. It's tempting to try to factor out a single DoFn that
would be used by FlatMapElements and FlatMapWithExceptions, or a single DoFn
that would be used by FlatMapWithExceptions and MapWithExceptions, but I'm
trying to avoid introducing too many wrapper functions or unused outputs. I
also like how FlatMapElements is fairly self-contained; there's a lot in the
class, but it tells you nearly all you need to know to understand how it works.
- I changed the interface to use `exceptionsInto` and `exceptionsVia`. This
removes the confusion over duplicated method names that @reuvenlax pointed to,
but maintains symmetry with the methods of FlatMapElements. I think the
symmetry is helpful to give users a hint that ordering of the methods remains
important (exceptionsInto must be called before exceptionsVia, just like into
must be called before via).
Once we have agreement on these changes, I'll make the corresponding changes
for MapElements.
I'd like some additional input on naming. I'm currently using a mixture of
"exception", "error", and "failure" and I'd like to tighten up that language.
"Exception" has a specific technical meaning that fits in well for talking
about an "exceptionHandler" and makes it explicit to users that the kind of
failures we're handling are indeed Java Exceptions, but once an exception is
handled and we transform it into some output element, it's no longer
technically an exception. We can call this output an "error element", but
"Error" is problematic because it also has a specific technical meaning in Java
that is not relevant to this situation. "Failure" doesn't have the problem of
an overloaded technical meaning, but seems slightly less natural than "error".
So, are `Result#output()` and `Result#errors()` reasonable names or would
`Result#failures()` be better? And `WithExceptions` might be better called
`WithFailures`, although that makes it less obvious that it's intended to be
used for exception handling specifically.
----------------------------------------------------------------
This is an automated message from the Apache Git Service.
To respond to the message, please log on GitHub and use the
URL above to go to the specific comment.
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org
Issue Time Tracking
-------------------
Worklog Id: (was: 201340)
Time Spent: 8h 10m (was: 8h)
Remaining Estimate: 159h 50m (was: 160h)
> Add exception handling to single message transforms in Java SDK
> ---------------------------------------------------------------
>
> Key: BEAM-5638
> URL: https://issues.apache.org/jira/browse/BEAM-5638
> Project: Beam
> Issue Type: Improvement
> Components: sdk-java-core
> Reporter: Jeff Klukas
> Assignee: Jeff Klukas
> Priority: Minor
> Labels: triaged
> Original Estimate: 168h
> Time Spent: 8h 10m
> Remaining Estimate: 159h 50m
>
> Add methods to MapElements, FlatMapElements, and Filter that allow users to
> specify expected exceptions and tuple tags to associate with the with
> collections of the successfully and unsuccessfully processed elements.
> See discussion on dev list:
> https://lists.apache.org/thread.html/936ed2a5f2c01be066fd903abf70130625e0b8cf4028c11b89b8b23f@%3Cdev.beam.apache.org%3E
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
