Exception Handling in Functional and Reactive Programming by Venkat Subramaniam

Functional and reactive programming is gaining popularity and use. One hurdle developers face using these approaches is in exception handling. Dealing with exceptions in these styles is confusing in the beginning and is often messy and error prone. In this presentation we will step back and take a closer look at exception handling, about their role in functional and reactive programming, and discuss the dos and don'ts for exception handling. We will learn using concrete examples and live coding to illustrate the problem and the possible solutions.
VENKAT SUBRAMANIAM
Dr. Venkat Subramaniam is an award-winning author, founder of Agile Developer, Inc., and an instructional professor at the University of Houston. He has mentored tens of thousands of software developers in the US, Canada, Europe, and Asia, and is a regularly-invited speaker at several international conferences. Venkat helps his clients effectively apply and succeed with agile practices on their software projects.
Venkat is a (co)author of multiple books, including the 2007 Jolt Productivity award winning book Practices of an Agile Developer. His latest book is Programming Kotlin: Create Elegant, Expressive, and Performant JVM and Android Applications. Venkat is a well-recognized person in the software communities. He was once a recipient of the MicroSoft MVP award.
He has received JavaOne RockStar award three years in a row and was inducted into the Java Champions program in 2013 for his efforts in motivating and inspiring software developers around the world.
Venkat has been in the training, consulting, and mentoring business since 1996. He is recognized for his pragmatic approach, dislike for accidental complexity, continuous effort to seek minimalistic design, and simpler solutions.
------------------------------------------------------------
INTRO
* visuals & editing by @Mercator
* music : Avocado by Ephixa

[@SamPainter11]

I feel like some discussion of the Either Monad and Validation type would add to this talk as well. When processing a stream being able to collect not just the exceptions but the objects that had exceptions is useful.

[@TJ-hs1qm]

The "Functional core, imperative shell" approach has been working in many situations for me. Basically, it means letting the imperative part of the code handle the tricky stuff like side effects and exceptions, and it fits nicely with the principles of Clean Architecture.

[@AmmarHusain007]

There is not a single talk by Venkat where in I don't feel "enlightened" ! Thanks for this insightful talk, it helps in making an informed choice when dealing with the dreaded exceptions. 😇

[@kappaj01]

Excellent talk as usual. Well worth the time to go through it all. Really like your approach to rather stick with imperative when running into many exceptions.

[@salehhassan6057]

Venkat, you are best

[@anitsh]

As always, excellent presentation by Venkat sir. There are so many implementing to flow with the trend and using tools unnecessarily and unknowingly. Forcing the functional style without the deeper understanding of the language support might have backfired even when tried with the good intent. This is a must watch.

[@simonfarre4907]

He's describing exceptions as results. There are languages that deal with this. Rust has an Option type and a Result type. C++ has std::optional and soon std::expected is coming, so on and so forth. Using exceptions for these things are an absolute terrible way to program. Unfortunately though, that's what Java has done all these years and Python does it as well. It is none the less terrible. The optional types and the expected/result types are far, far superior and come with way less overhead - and they enforce checking, without cluttering up everything in try / catch blocks. Exceptions should only be used for the truly exceptional.

[@MarcelRiegler]

I agree, and sadly even Kotlin doesn't quite get this right. They removed checked exceptions, but they didn't add any idiomatic way to do "monad--ish comprehensions" on result types. Aka, the "?" in Rust, which immediately returns the error, or simply continues if no error is present.

[@marianobarcia]

Also of note is that stream processing stops if any runtime exception happens while in the middle of processing said stream. Great talk, really enjoyed the story about keeping calm and not missing that flight ✈️ 😅

[@rostyslavpaliuha225]

Venkat I appreciate your mindful position to Ukrainie , respect for flag at tweeter!!!

[@driden1987]

Hmm, it's a "functional" in the sense that you are chaining functions. Throwing exceptions is not functional code. Like other viewers pointed out, taking a look at how more functional languages use different monads to do error handling would have been proper.

[@stephenpaul7499]

I use the functional interface 'hack' because if my stream fails, I don't want to ignore the error and continue. I want it to fail completely. I also don't use parallel streams, and I don't mind the slightly longer stack trace if it means cleaner code at the end. If I want to 'continue' after an error is thrown (which is not common) I use the imperative style.

[@nguyenquan4836]

Super

[@amanbains5474]

Hi Nana , Very nice explanation !! Can you please elaborate why companies are not using IstioD due to Side cars as many teams are handling it via Kubernetes alone !! Any feedback will be appreciated

[@adambickford8720]

Checked exceptions are a unique java mistake that keeps on giving. I wonder how popular a 'disable checked exceptions' would be for greenfield projects?

[@omnipoten8]

I think we are still left with the question unanswered : How to handle checked exceptions in functional pipelines in elegant and non-hacky way !

[@vmihaylov76]

The answer was pretty obvious :-). Don't use code that throws exceptions in functional pipelines 😀

[@omnipoten8]

@@vmihaylov76 I agree . But in Java world is it not always easy to get rid of checked exceptions .

[@vmihaylov76]

@@omnipoten8 Absolutely! My takeaway from this talk was to get rid of the functional pipelines when I can't get rid of the exceptions. Imperfect but practical.

[@omnipoten8]

@@vmihaylov76 yeah , but then we will miss the beauty and the performance efficiency of functional pipelines for anything that involves IO operations . Remember how tricky is it to wrote code for work stealing algorithm via fork-join pools ;)

[@275drago]

@Sneaky Throws in lombok :D

[@USONOFAV]

Brian Goetz hated that FunctionEx interface workaround, lol.

[@matijacvrk8299]

sapienti sat

[@liuckan]

1:19:36 - part 2 ;)

[@UnitedFeodor]

1:21:30

[@kennethcarvalho3684]

This is the one topic still confused...in case anyone knows any bible or seminal text article please share.

[@ashmantak]

Why are his talks so long always ?

[@DevoxxForever]

These are Deep Dive Devoxx sessions of max 3 hours. 😉👍

[@VitaliyKulikovUA]

@SneakyThrows (Lombok) - convert Checked to Runtime Mono/Flux onErrorContinue(BiConsumer errorConsumer) - Reactor onErrorXXXX(...)

[@gunjanbasak8431]

Converting Checked Exception to Runtime Exception is just escaping the actual problem. Watch 34:17

[@smanqele]

In other words, don't be functional zealots!

[@updownftw_]

Why doesn’t he just use a code editor ?

[@phucosg]

That is his code editor

[@gerke_kok]

Ever wonder how the layout of the run-results work? I imagine he has his own presentation editor. Would love to study that 🙂

[@gerke_kok]

(layover)

[@VitaliyKulikovUA]

vim with plugins

[@aksh1618]

This is the way

[@VitaliyKulikovUA]

not true for reactive api var items = List.of("1", "2", "a", "3"); Flux.fromIterable(items) .map(Integer::valueOf) .onErrorContinue((error, data) -> System.out.println(error + " for " + data)) .subscribe(System.out::println); } /// 1 2 java.lang.NumberFormatException: For input string: "a" for a 3

[@RonTheFlyingDutchman]

Venkat uses RxJava. Could be a difference between RxJava and Spring WebFlux.

[@VitaliyKulikovUA]

@@RonTheFlyingDutchman Observable.fromIterable(items)