Meta tags:
description=Java s checked exceptions are both an integral part of the language and one of its most contested features. Let s talk about specific issues with checked exceptions and what could be done about them.;

Headings (most frequently used words):

exceptions, checked, towards, better, inside, java, newscast, 107, inherited, checkedness, too, many, catching, unthrown, functional, error, handling, and, deferred, computation, stylistic, changes,

Text of the page (most frequently used words):
the (112), that (81), and (61), checked (51), java (51), exceptions (47), #exception (35), path (34), for (32), either (32), you (31), this (28), but (27), ioexception (23), string (23), with (21), error (21), stream (21), throws (18), can (17), could (17), readstring (16), project (15), paths (15), not (14), there (13), just (13), try (13), they (13), sql (13), are (13), would (12), example (12), one (12), method (12), all (12), what (11), more (11), them (11), code (11), other (10), where (10), about (10), let (10), way (10), because (10), handling (10), also (10), throw (10), map (10), type (10), list (10), charset (10), need (9), have (9), types (9), statement (9), sqlexception (9), from (9), like (9), two (8), catch (8), doesn (8), don (8), switch (8), well (8), which (8), than (7), better (7), specific (7), methods (7), preparestatement (7), use (7), here (7), your (7), when (7), many (7), think (6), information (6), too (6), apis (6), functional (6), unchecked (6), returns (6), return (6), deferred (6), tolist (6), filecontents (6), pipeline (6), operation (6), why (6), var (6), catching (6), has (5), very (5), instead (5), work (5), move (5), know (5), changes (5), these (5), want (5), different (5), some (5), change (5), something (5), get (5), their (5), those (5), even (5), situations (5), same (5), language (5), case (5), handle (5), computation (5), its (5), right (5), newscast (5), community (5), junit (5), long (4), easy (4), lot (4), talk (4), comments (4), towards (4), calls (4), libraries (4), space (4), thrown (4), then (4), works (4), into (4), generics (4), contents (4), most (4), call (4), value (4), turn (4), jdk (4), may (4), utf8 (4), utf (4), getbytes (4), particularly (4), part (4), close (4), inherited (4), checkedness (4), hierarchy (4), openjdk (4), inside (4), privacy (3), youtube (3), will (3), problem (3), hard (3), make (3), good (3), course (3), believe (3), pattern (3), matching (3), cases (3), domain (3), nothing (3), optional (3), been (3), our (3), stylistic (3), does (3), were (3), expression (3), say (3), generic (3), out (3), elsewhere (3), point (3), api (3), compile (3), now (3), needs (3), executes (3), mean (3), calling (3), much (3), chain (3), first (3), lambda (3), requires (3), bunch (3), while (3), downsides (3), video (3), another (3), makes (3), annoying (3), really (3), unthrown (3), only (3), without (3), conversation (3), watch (3), follow (3), share (3), 107 (3), next (3), pioneer (3), demos (3), streams (3), core (3), clean (3), license (2), rss (2), stackoverflow (2), github (2), twitch (2), discord (2), mastodon (2), bluesky (2), again (2), train (2), few (2), small (2), yield (2), thought (2), needle (2), mechanisms (2), others (2), fact (2), chunk (2), essential (2), difficulty (2), stack (2), through (2), absolutely (2), should (2), together (2), create (2), style (2), preference (2), done (2), any (2), encounter (2), beyond (2), draft (2), ability (2), instance (2), useful (2), description (2), flatmapright (2), track (2), feature (2), both (2), users (2), easily (2), form (2), compiler (2), multiple (2), features (2), improve (2), ignore (2), transporting (2), note (2), sometimes (2), files (2), won (2), passing (2), build (2), means (2), operations (2), second (2), filecontent (2), left (2), was (2), readpreparedstatement (2), solution (2), might (2), help (2), introducing (2), aspect (2), still (2), things (2), around (2), trying (2), positive (2), catches (2), never (2), unfortunately (2), longer (2), namely (2), such (2), block (2), declares (2), every (2), classes (2), issues (2), isolate (2), places (2), anything (2), time (2), forname (2), issupported (2), static (2), name (2), before (2), bytes (2), takes (2), exists (2), unsupportedencodingexception (2), take (2), state (2), dislike (2), bytearrayinputstream (2), possibly (2), whether (2), making (2), great (2), allows (2), unified (2), access (2), yes (2), going (2), fruitful (2), off (2), integral (2), recent (2), active (2), various (2), platforms (2), notified (2), publish (2), new (2), content (2), post (2), videos (2), talks (2), libfx (2), record (2), args (2), year (2), tools (2), techniques (2), serialization (2), reflection (2), records (2), valhalla (2), panama (2), loom (2), leyden (2), amber (2), performance (2), patterns (2), ramp (2), migration (2), meta (2), maven (2), javafx (2), basics (2), j_ms (2), dop (2), documentation (2), deprecation (2), libs (2), collections (2), architecture (2), tags (2), javascript (2), contact, imprint, see, weeks, hurry, wait, unfortunate, consequence, pareto, principle, play, improvements, large, results, anybody, claiming, probably, seems, required, tackle, usable, end, none, variants, nor, failure, languages, errors, rip, inherently, tradeoffs, genuinely, aggregate, big, complexity, general, communicate, across, frames, abstractions, plagues, logging, rely, express, teams, guide, matches, who, mind, aggressively, replace, erro, except, letting, high, level, handler, wrapping, correct, options, straightforward, helper, wrap, accordingly, yeah, low, effort, everything, exactly, burdensome, accepted, tests, whatever, write, scripts, programs, applied, empty, readpath, deserves, mention, jep, gain, selector, corrected, successful, branches, essentially, recoverable, linked, multple, simple, back, stick, declaring, pure, library, component, turns, checkedexception, single, parameter, beefed, collect, nerd, terminology, approaches, achieve, similar, outcomes, union, variadic, overall, complex, admittedly, entirely, speculative, hear, getright, isright, filter, remove, processing, returning, struggle, registering, executing, despite, shortcomings, handy, often, comes, lambdas, mostly, missing, ping, details, outright, impossibility, carried, resulting, carries, hypothetical, produce, transported, passed, trigger, execution, capture, run, issue, described, earlier, surfaces, executed, yet, else, later, behalf, room, implicit, assumption, immediacy, least, directly, relevant, downside, moves, frankly, sucks, kinds, quickly, escalate, removes, system, improvement, conceptually, fails, succeeds, result, disappear, easier, pass, add, clause, happen, stuck, opinion, niche, observe, functionally, segment, called, argue, utility, advice, pretty, limited, already, running, how, link, explanation, below, button, soon, invoke, keep, compiling, far, begrudgingly, middle, working, piece, comment, anymore, undo, constantly, yell, rafters, line, shot, removing, handful, impact, decent, unnecessary, removed, each, breaking, helpful, approach, relax, bit, aren, own, careful, consideration, body, corresponding, hello, println, changing, source, incompatible, demands, reduction, daunting, specifically, possible, buffer, states, throwing, although, printwriter, printstream, able, restructure, extracted, giving, chance, fewer, revisit, consider, splitting, necessary, summarize, ecosystem, situation, successfully, decreases, counter, less, convinced, improves, marinate, maybe, fodder, interestingly, factory, illegal, considered, programming, supposed, instantiate, named, worked, base, ugh, fixed, overload, character, set, initial, specify, suboptimal, design, lead, being, prominent, bundle, functionality, dealing, worse, subclasses, force, deal, subtype, wonder, closing, effect, javadoc, says, closethestream, void, demo, overly, liberal, outputstream, inputstream, thing, provide, important, diligently, sense, reason, creating, root, decide, inheriting, likely, err, side, find, detailed, mark, apply, individual, larger, marker, interface, related, problems, expected, gives, codes, extend, shouldn, recourse, almost, syntax, invalid, authentication, bug, program, sqlinvalidauthorizationspecexception, sqlsyntaxerrorexception, depends, sits, extends, determining, property, via, inheritance, collides, reasons, runtimeexception, longest, intro, ever, behind, ready, dive, brings, actually, developers, devs, flustered, created, sharp, edges, ones, realistically, file, actionable, steps, repeating, flame, war, goes, uncheckedioexcpetion, understanding, within, net, subjective, due, objective, benefits, argument, made, countless, times, counterarguments, energy, getting, anywhere, operating, position, remain, beneficial, otherwise, brian, goetz, enjoys, suffering, stay, welcome, everyone, cover, developments, nicolai, parlog, developer, advocate, oracle, today, place, german, station, discuss, unlike, episodes, triggered, proposal, kind, evolving, coming, years, address, must, bad, please, parts, toc, table, policy, give, cookie, remember, always, embed, contested, 2026, slides, upcoming, past, schedule, recordings, virtual, threads, vector, structured, concurrency, lilliput, galahad, babylon, book, club, jms, newsletter, blog, posts, testing, rant, jigsaw, jdeps, impulse, default, lang, review, words, site, enabled, nipafx,

Text of the page (random words):
y created uncheckedioexcpetion so what are sharp edges and which ones could openjdk realistically file off let s talk about actionable steps instead of just repeating the same flame war and this also goes for the comments by the way ok with what may well have been the longest newscast intro ever behind us let s get going ready then let s dive right in inherited checkedness as you know whether an exception is checked or not depends on where it sits in the exception type hierarchy if it extends runtimeexception it s unchecked if it doesn t it s checked and yes we ll ignore error s unfortunately determining this essential property via inheritance collides with other reasons to build a type hierarchy in this case particularly with unified error handling and access to information a good example is sqlexception catching it allows handling all sql related problems that code can be expected to encounter and it gives unified access to error codes and the sql state but because it s checked so are all exceptions that extend it and there are a bunch of them that really shouldn t be for example what s the recourse when catching sqlsyntaxerrorexception or sqlinvalidauthorizationspecexception in almost all situations an sql syntax error or invalid db authentication is a bug in the program and so the exception should be unchecked so when creating an exception type as the root for a domain specific exception hierarchy you need to decide for all inheriting exceptions whether they ll be checked or not and if you believe in the value of checked exceptions like openjdk does then you re very likely to err on the side of making them all checked instead of all unchecked all that to say it would be great if java would find a more detailed way to mark exceptions as checked or unchecked one that allows us to apply that to individual types in a larger hierarchy for example through a marker interface too many checked exceptions because here s the thing that checked exceptions provide value doesn t mean that they don t have downsides which means it s important to use them diligently and only where it makes sense for the code calling a method to handle its error inherited checkedness is one reason why there are too many checked exceptions but it s not the only one another is just overly liberal use of them take inputstream s and outputstream s close methods for example they throw the checked ioexception but what can you possibly do when catching them just a demo not a particularly useful method void closethestream bytearrayinputstream stream try stream close catch ioexception ex what could i possibly do close again also the javadoc says closing a bytearrayinputstream has no effect worse these two classes and a bunch of their subclasses state that close doesn t even do anything so they force you to deal with an exception they never throw because some subtype might no wonder so many of us dislike checked exceptions suboptimal api design can also lead to checked exceptions being more prominent than they need to be apis sometimes bundle functionality where only one part throws a checked exception but without a way to isolate that aspect every call requires dealing with this exception take jdk methods like string getbytes for example it needs a character set and in the method s initial form you d specify the charset by name but what if no such charset exists that s why getbytes throws the checked unsupportedencodingexception throws unsupportedencodingexception particularly annoying we know utf 8 exists var bytes string getbytes utf 8 so even if the named charset worked well for the other 10 places in your code base you still need to handle the checked exception here ugh java 6 fixed this by introducing an overload that takes a charset instance no exception is thrown charset utf8 var bytes string getbytes utf8 but interestingly the static factory method charset forname doesn t throw a checked exception passing it an illegal name is considered a programming error because there s also the static method issupported which you re supposed to use before trying to instantiate a charset if charset issupported utf 8 declares no checked exception var utf8 charset forname utf 8 use utf8 that successfully decreases the checked exception counter by one but the longer i think about it the less convinced i am that it really improves anything but that s a thought that needs more time to marinate maybe fodder for another video for now let s summarize a few things libraries the jdk as well as others in the ecosystem can do to improve the situation they can revisit which exceptions need to be checked and consider splitting exception types if necessary they may also be able to restructure apis so that operations that throw checked exception are extracted from those that don t giving users the chance to isolate error handling in fewer places just like with the charset example it may also be possible to buffer error states instead of throwing on every call an example for this would be printstream and printwriter although these classes have other issues catching unthrown exceptions unfortunately there s a problem with changing an api to no longer throw a checked exception namely that such a change is source incompatible a try catch block that catches a specific checked exception demands that something in the try block declares to throw it which makes the reduction of checked exceptions daunting specifically for jdk apis try io println hello exceptions error exception ioexception is never thrown in body of corresponding try statement catch ioexception ex and it s not like removing a handful of them would move the needle for this to have a positive impact a decent chunk of checked exceptions would have to turn out to be unnecessary and removed each of them a breaking change so it would be really helpful for this approach if the compiler could relax a bit and let us compile code that catches checked exceptions that aren t thrown this has its own downsides of course so it requires careful consideration but it would also help with another aspect that makes checked exceptions annoying as soon as you invoke a method that throws you need to do something to keep the code compiling so far so begrudgingly good but then when you re still in the middle of working on that piece of code and comment out a method or move things around and nothing throws the exception anymore you need to undo all that so checked exceptions constantly yell at you from the rafters while you re trying to line up your shot very annoying functional error handling and deferred computation this segment might as well be called just use either and while that can help i d argue that the utility of this advice is pretty limited this video is already running long so i m not introducing how either works if you don t know there s a link to an explanation in the description 1 2 right below the like button first of all let s observe that a method that returns a value but can throw a checked exception is functionally the same as a method that returns something like an either of that value or that exception string readstring path path throws ioexception either ioexception string readstring path path but handling an either vs an exception is of course different and there are two downsides that in my opinion make either a niche solution in java one is that exceptions are much easier to pass up the call stack if you don t want to handle them right there just call a bunch of methods and add their exceptions to your throws clause with either all those calls need to happen in a functional pipeline and while i like those more than most i absolutely don t want all my code to be stuck in them chain calls of these two methods string readstring path path throws ioexception statement preparestatement string sql throws sqlexception statement readpreparedstatement path path throws ioexception sqlexception var filecontent readstring path return preparestatement filecontent chain calls of these two methods either ioexception string readstring path path either sqlexception statement preparestatement string sql requires functional pipeline specific exception types disappear either exception statement readpreparedstatement path path return readstring path if the either was left this does nothing if the either was right it executes the lambda if that succeeds it returns the result as right if that fails it returns the exception as left conceptually either ioexception sqlexception or a statement flatmapright sql preparestatement sql the other and much more relevant downside is that either moves the type information from throws into a generic type and frankly that sucks because it means that when you chain operations that can throw different kinds of exceptions say the first an ioexception and the second an sqlexception the either s generic type will quickly escalate to just exception which removes a lot of information from the type system in most situations this is not an improvement but that doesn t mean that there s no room for either either checked exceptions build on an implicit assumption of immediacy an operation can throw an exception and because you re calling the operation you need to handle the exception but what if you re not calling the operation or at least not directly in a stream pipeline for example you re passing the operation on and something else executes it later on your behalf stream string filecontents list path paths return paths stream won t compile because readstring throws ioexception but note that it doesn t get executed yet map files readstring elsewhere list path paths tolist executes the stream pipeline so if readstring throws any exception it surfaces here list string contents filecontents paths tolist now the fact that your operation can produce an error needs to be transported from where you passed it to where you trigger the execution for example from a stream map to its tolist you could try to capture the exception types with generics but you ll run into the same issue i described earlier stream string ioexception filecontents list path paths return paths stream in this hypothetical api this would compile and the resulting stream carries the exception type map files readstring elsewhere list path paths tolist throws the carried exception here ioexception try list string contents filecontents paths tolist catch ioexception ex and the difficulty or sometimes outright impossibility of transporting the error information is why checked exceptions and deferred computation don t work well together note this often comes up as lambdas don t work with checked exceptions but that s mostly missing the point ping me in the comments if you want me to go into more details on that so checked exceptions struggle with transporting type information from registering to executing a deferred operation you know what doesn t either which is why despite its shortcomings it s very handy in specific situations like in a stream pipeline use either returning method for stream pipeline either ioexception string readstring path path stream either ioexception string filecontents list path paths return paths stream map path readstring path elsewhere list path paths list string contents filecontents paths example for processing the stream of either ioexception string here remove ignore all error cases filter either isright map either getright tolist and i think there are two java features that could improve this overall problem complex admittedly they are entirely speculative but hear me out one could be the ability of the java compiler to track multiple checkedexception types in a single generic parameter that way an either or a beefed up stream could easily collect multiple checked exceptions the language nerd terminology for this would be variadic generics or union types two different approaches that could achieve similar outcomes for our use case the other feature could be a simple way to go from a method that returns and throws to an either of both and back then apis could stick to declaring return types and checked exceptions but their users could easily switch to a form that works better for deferred computation this could be a pure library feature but it could also have a language component where try turns into an expression that returns an either string readstring path path throws ioexception statement preparestatement string sql throws sqlexception list path paths if stream t ex could track multple exception types stream statement ioexception sqlexception paths stream map path readstring path map sql preparestatement sql if it were easy to switch to either say with try stream either ioexception sqlexception statement paths stream map path try readstring path map sql sql flatmapright s try preparestatement s one language change in this space that deserves a mention and does have a jep draft is for switch to gain the ability to handle exceptions that were thrown by the selector expression in situations where the error case can be corrected to yield an instance of the same type as the successful branches this would be very useful it s essentially try as an expression for recoverable cases the draft is also linked in the description string readstring path path throws ioexception if switch could catch exceptions string sql switch readpath path case string s s map the error case to the empty string catch ioexception _ stylistic changes beyond the changes that could be applied to the language or to libraries i think our style can change as well for example it has long been accepted that tests just throw whatever exception they encounter if we write scripts or other small programs we can just do the same for those of us who don t mind functional apis we can aggressively replace checked exceptions with either try or even just optional and in situations where nothing can be done about an erro except letting a high level handler catch it wrapping a checked exception in an unchecked one is correct and easy to do too for any of those options it s straightforward to create helper methods that wrap method calls accordingly yeah it s not as low effort as a make everything unchecked switch but it s also not exactly burdensome or as we move towards more apis that rely on pattern matching we can express some error cases through domain specific types either way teams absolutely should get together and create a style guide for their project that matches their domain and preference but in the end i think none of these variants nor the failure mechanisms of other languages by the way will be easy to work with if you want to do more than just let errors rip because good error handling is hard inherently of course different mechanisms have different tradeoffs and i genuinely believe that some can in aggregate be better than others but that doesn t change the fact that a big chunk of the complexity is essential an example is the general difficulty to commun...