What in Beam codebase is not ready, and how do we know that user code doesn't have the same issue?
On Sun, Oct 14, 2018 at 6:04 AM Romain Manni-Bucau <rmannibu...@gmail.com> wrote: > Hmm, tested also and it works until something in the codeflow does not > respect that constraint - see > com.sun.tools.javac.comp.Flow.FlowAnalyzer#errorUncaught. In other words > beam codebase is not ready for that and will make it fail but it is ok > cause we can fix it but user code does not rely on that so it is fine to > update it normally. > > Romain Manni-Bucau > @rmannibucau <https://twitter.com/rmannibucau> | Blog > <https://rmannibucau.metawerx.net/> | Old Blog > <http://rmannibucau.wordpress.com> | Github > <https://github.com/rmannibucau> | LinkedIn > <https://www.linkedin.com/in/rmannibucau> | Book > <https://www.packtpub.com/application-development/java-ee-8-high-performance> > > > Le dim. 14 oct. 2018 à 14:39, Reuven Lax <re...@google.com> a écrit : > >> Just tried it, doesn't appear to work :( >> >> error: unreported exception Exception; must be caught or declared to be >> thrown >> >> On Sun, Oct 14, 2018 at 1:55 AM Romain Manni-Bucau <rmannibu...@gmail.com> >> wrote: >> >>> not with java>=8 AFAIK >>> >>> Romain Manni-Bucau >>> @rmannibucau <https://twitter.com/rmannibucau> | Blog >>> <https://rmannibucau.metawerx.net/> | Old Blog >>> <http://rmannibucau.wordpress.com> | Github >>> <https://github.com/rmannibucau> | LinkedIn >>> <https://www.linkedin.com/in/rmannibucau> | Book >>> <https://www.packtpub.com/application-development/java-ee-8-high-performance> >>> >>> >>> Le dim. 14 oct. 2018 à 10:49, Reuven Lax <re...@google.com> a écrit : >>> >>>> But it means that other functions that call SerializableFunctions must >>>> now declare exceptions, right? If yes, this is incompatible. >>>> >>>> On Sun, Oct 14, 2018 at 1:37 AM Romain Manni-Bucau < >>>> rmannibu...@gmail.com> wrote: >>>> >>>>> No, only parameter types and return type is used to lookup methods. >>>>> >>>>> Romain Manni-Bucau >>>>> @rmannibucau <https://twitter.com/rmannibucau> | Blog >>>>> <https://rmannibucau.metawerx.net/> | Old Blog >>>>> <http://rmannibucau.wordpress.com> | Github >>>>> <https://github.com/rmannibucau> | LinkedIn >>>>> <https://www.linkedin.com/in/rmannibucau> | Book >>>>> <https://www.packtpub.com/application-development/java-ee-8-high-performance> >>>>> >>>>> >>>>> Le dim. 14 oct. 2018 à 09:45, Reuven Lax <re...@google.com> a écrit : >>>>> >>>>>> I've run into this problem before as well. Doesn't changing the >>>>>> signature involve a backwards-incompatible change though? >>>>>> >>>>>> On Wed, Oct 3, 2018 at 5:11 PM Jeff Klukas <jklu...@mozilla.com> >>>>>> wrote: >>>>>> >>>>>>> I'm working on https://issues.apache.org/jira/browse/BEAM-5638 to >>>>>>> add exception handling options to single message transforms in the Java >>>>>>> SDK. >>>>>>> >>>>>>> MapElements' via() method is overloaded to accept either a >>>>>>> SimpleFunction, a SerializableFunction, or a Contextful, all of which >>>>>>> are >>>>>>> ultimately stored as a Contextful where the mapping functionis expected >>>>>>> to >>>>>>> have signature: >>>>>>> >>>>>>> OutputT apply(InputT element, Context c) throws Exception; >>>>>>> >>>>>>> So Contextful.Fn allows throwing checked exceptions, but neither >>>>>>> SerializableFunction nor SimpleFunction do. The user-provided >>>>>>> function has to satisfy the more restrictive signature: >>>>>>> >>>>>>> OutputT apply(InputT input); >>>>>>> >>>>>>> Is there background about why we allow arbitrary checked exceptions >>>>>>> to be thrown in one case but not the other two? Could we consider >>>>>>> expanding >>>>>>> SerializableFunction and SimpleFunction to the following?: >>>>>>> >>>>>>> OutputT apply(InputT input) throws Exception; >>>>>>> >>>>>>> This would, for example, simplify the implementation of ParseJsons >>>>>>> and AsJsons, where we have to catch an IOException in MapElements#via >>>>>>> only >>>>>>> to rethrow as RuntimeException. >>>>>>> >>>>>>
