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. >>>>>> >>>>>
