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):
n dop generics impulse j_ms java 10 java 11 java 12 java 13 java 16 java 17 java 18 java 20 java 23 java 24 java 25 java 26 java 27 java 8 java 9 java basics java next javafx jdeps js junit 5 junit pioneer lambda libfx libraries maven meta migration on ramp optional pattern matching patterns performance project amber project jigsaw project leyden project loom project panama project valhalla rant record args records reflection serialization streams switch techniques testing tools turn of the year var blog posts newsletter the jms videos tags ai architecture book club clean code collections community conversation core libs deprecation documentation dop generics j_ms java 10 java 11 java 12 java 16 java 17 java 18 java 19 java 21 java 22 java 23 java 24 java 25 java 26 java 27 java 28 java 8 java 9 java basics java next javafx junit 5 junit pioneer lambda libraries maven meta migration on ramp openjdk optional pattern matching patterns performance project amber project babylon project galahad project leyden project lilliput project loom project panama project valhalla records reflection serialization streams structured concurrency switch techniques tools turn of the year var vector virtual threads recordings streams schedule code demos demos demos junit pioneer record args libfx talks my talks past upcoming slides about about me license privacy 2026 02 19 towards better checked exceptions inside java newscast 107 video java next 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 always embed videos and give me a cookie to remember privacy policy watch on youtube towards better checked exceptions inside java newscast 107 table of contents inherited checkedness too many checked exceptions catching unthrown exceptions functional error handling and deferred computation stylistic changes share follow share this post with your community i m active on various platforms watch this space or follow me there to get notified when i publish new content toc inherited checkedness too many checked exceptions catching unthrown exceptions functional error handling and deferred computation stylistic changes s f share this post with your community i m active on various platforms watch this space or follow me there to get notified when i publish new content welcome everyone to the inside java newscast where we cover recent developments in the openjdk community i m nicolai parlog java developer advocate at oracle and today we re going to talk about exceptions and what better place to do that than a german train station so why discuss exceptions and particularly checked exceptions now unlike most other episodes this one is not triggered by a specific proposal it s kind of the other way around with java evolving a lot in recent and coming years it may well address error handling at some point but for that conversation to be fruitful we must move beyond checked exceptions bad turn off please and there are two parts to that first understanding that within the solution space for error handling in java checked exceptions are a net positive yes i like checked exceptions and more than that i think it s not just subjective preference but due to objective benefits but i won t be making that argument here it has been made countless times before with just as many counterarguments and it takes up a lot of time and energy without getting us anywhere instead we ll be operating from the position that checked exceptions remain an integral part of java because they re beneficial or otherwise because brian goetz enjoys our suffering either way they re here to stay which brings us to the second part and the conversation i actually want to have one that i believe would be much more fruitful namely if checked exceptions are so great why do so many developers dislike them i mean even the jdk devs were at some point so flustered that they 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 situat...
|
