TE
TechEcho
Home24h TopNewestBestAskShowJobs
GitHubTwitter
Home

TechEcho

A tech news platform built with Next.js, providing global tech news and discussions.

GitHubTwitter

Home

HomeNewestBestAskShowJobs

Resources

HackerNews APIOriginal HackerNewsNext.js

© 2025 TechEcho. All rights reserved.

Checked exceptions: Java’s biggest mistake (2014)

114 pointsby flying_sheepover 4 years ago

44 comments

alasdair_over 4 years ago
I like checked exceptions. Yes, sometimes (especially in the oldest APIs when they were still figuring this stuff out), they were overused but mostly I think they encourage developers to really think about what happens in the failure case.<p>I notice this especially with less experienced developers and remote calls - a lot of JS code I’ve reviewed in the past assumes the remote call will always work, yet Java code from the <i>same</i> developer will almost always correctly handle the situation, simply because the exception is explicitly required to be handled.
评论 #24446032 未加载
评论 #24445295 未加载
评论 #24446909 未加载
评论 #24444919 未加载
评论 #24448406 未加载
hrgigerover 4 years ago
Well... I will take the bullet and confess that I do like checked exceptions. When they are not miss|over used they transfer the enough required knowledge what is to be handled. You dont need to handle? Transfer to higher levels on stack. That is a great fit in my opinion for applications designed with especially fault tolerance futures and using many external components. Not saying that design of CE is perfect, they might be too broad that doesnt tell you exact handle case, so it will leave you in the dark or in a call chain of a()-&gt;b()-c()-d() there might be cases that b and c wouldnt need to have contract in their method signature maybe compiler would decide if exception is orphaned or needs to be handled.
评论 #24444368 未加载
gordacoover 4 years ago
I don&#x27;t really dislike the concept of checked exceptions, but the awful way they prevent the usage of functional interfaces and modern Java in general is pretty infuriating. Functional interfaces and code that uses them should have a generic way of being transparent to exceptions, but I&#x27;m not sure it can be done without breaking the language.<p>Nevertheless, I still believe that Java&#x27;s biggest mistake is not checked exceptions, but the stupid distinction between primitive types and Objects (caused because all the cruft present in the latter would have make basic operations prohibitive in terms of performance, at least for early Java versions) and all the associated boxing. I have seen some extreme cases of performance degradation because of that (fortunately a refactor to use arrays solved the problem, but this is not always possible).
评论 #24444507 未加载
评论 #24444538 未加载
评论 #24447611 未加载
aazaaover 4 years ago
&gt; The biggest argument against “checked” exceptions is that most exceptions can’t be fixed. The simple fact is, we don’t own the code&#x2F; subsystem that broke. We can’t see the implementation, we’re not responsible for it, and can’t fix it.<p>Here&#x27;s what Oracle has to say:<p>&gt; Here&#x27;s the bottom line guideline: If a client can reasonably be expected to recover from an exception, make it a checked exception. If a client cannot do anything to recover from the exception, make it an unchecked exception.<p><a href="https:&#x2F;&#x2F;docs.oracle.com&#x2F;javase&#x2F;tutorial&#x2F;essential&#x2F;exceptions&#x2F;runtime.html" rel="nofollow">https:&#x2F;&#x2F;docs.oracle.com&#x2F;javase&#x2F;tutorial&#x2F;essential&#x2F;exceptions...</a><p>- checked exception for recoverable errors<p>- unchecked exception for non-recoverable errors<p>So the argument that most errors can&#x27;t be recovered from is _not_ a reason to abandon checked exceptions. It&#x27;s a reason to reserve checked exceptions for those cases in which recovery is likely.<p>The main argument in this article appears to be based on a misunderstanding.
评论 #24447457 未加载
评论 #24448382 未加载
评论 #24448457 未加载
评论 #24448191 未加载
评论 #24448359 未加载
评论 #24448225 未加载
评论 #24447466 未加载
评论 #24447151 未加载
specialistover 4 years ago
How would eliminating checked exceptions mitigate terrible API design?<p>I&#x27;ve never understood the angst. All the arguments reduce down to mitigating terrible abstractions.<p>The Correct Answer is better APIs. Mostly, that means don&#x27;t pretend the network fallacies don&#x27;t exist. Embrace them. Which generally means work closer to the metal.<p>I&#x27;ll say it another way. The problem is EJB, ORMs, Spring, etc. The obfuscation layers.<p>Someone smarter than me will have to rebut the functional programming points. I&#x27;d just use a proper FP language. Multiparadigm programming is a strong second on the list of stuff you shouldn&#x27;t do. (Metaprogramming is first.)
评论 #24444169 未加载
Imnimoover 4 years ago
Some checked exceptions make a lot of sense to try to catch and fix. FileNotFoundException is something my code can probably recover from - you asked for a file, it&#x27;s not there, let me ask for a different file. Having a file reading method declare that it throws FileNotFoundException can be a helpful reminder to make sure you handle that possibility.<p>But then there are other types of checked exceptions that are almost certainly unrecoverable because they happen way down in some other third party code. And then you get the endless chain of &quot;throws&quot; all the way back up the code base.
评论 #24444575 未加载
评论 #24444444 未加载
评论 #24446133 未加载
评论 #24448818 未加载
chriswarboover 4 years ago
I&#x27;ve been using Scala quite heavily recently, having mostly used Haskell for years, with distant memories of Java. Scala allows Java methods to be called, but doesn&#x27;t bother with checked exceptions, which has bitten me quite a few times.<p>My preferred style of error-handling is Option&#x2F;Either, since I can implement the &#x27;happy path&#x27; in small, pure pieces; plug them together with &#x27;flatMap&#x27;, etc.; then do error handling at the top with a &#x27;fold&#x27; or &#x27;match&#x27;.<p>Exceptions break this approach; but it&#x27;s easy to wrap problematic calls in &#x27;Try&#x27; (where &#x27;Try[T]&#x27; is equivalent to &#x27;Either[Throwable, T]&#x27;).<p>The problem is that Scala doesn&#x27;t tell me when this is needed; it has to be gleaned from the documentation, reading the library source (if available), etc.<p>I get that a RuntimeException could happen at any point; but to me the benefit of checked exceptions isn&#x27;t to say &quot;here&#x27;s what you need to recover from&quot;, it&#x27;s to say &quot;these are very real possibilities you need to be aware of&quot;. In other words checked exceptions have the spirit of &#x27;Either[Err, T]&#x27;, but lack the polymorphism needed to make useful, generic plumbing. The article actually points this out, complaining that checked exceptions have to be handled&#x2F;declared through &#x27;all intervening code&#x27;; the same can actually be said of &#x27;Option&#x27;, or &#x27;Either&#x27;, or &#x27;Try&#x27;, etc., but the difference is that their &#x27;intervening code&#x27; is usually calculated by the higher-order functions provided by Functor, Applicative, Monad, Traverse, etc.<p>It&#x27;s similar to many developer&#x27;s first experience of Option&#x2F;Maybe: manually unwrapping them, processing the contents, wrapping up the result, then doing the same for the next step, and so on. It takes a while to grok that we can just map&#x2F;flatMap each of our steps on to the last (or use &#x27;for&#x2F;yield&#x27;, do-notation, etc. if available). It would be nice to have a similar degree of polymorphism for checked exceptions. Until then, I&#x27;d still rather have them checked (so I can convert them to a &#x27;Try&#x27;), rather than getting no assistance from the compiler at all!
评论 #24444436 未加载
评论 #24443709 未加载
评论 #24443900 未加载
评论 #24443769 未加载
captainmuonover 4 years ago
I think checked exceptions are backwards. If you use a `throws` declaration the caller <i>must</i> catch it. It quickly becomes quite onerous. (Especially if you come from the philosophy that an exception often means &quot;abort this program - unless somebody catches this&quot;. In small programs you might just want it to crash early.) And even worse, it is not exhaustive. You can always get a RuntimeException or a NullPointerException from nowhere.<p>It would be great if they worked the other way around. Instead of <i>forcing the caller</i> to catch an exception, they would <i>guarantee</i> that no exception leaves a certain block.<p>So you would have a function<p><pre><code> void MyFunc() onlythrows IOException { first(); second(); } </code></pre> And the compiler would statically guarantee that no other exception can leak out of it - because first and second have been marked `onlythrows IOException` or are &quot;pure&quot; and cannot throw at all.<p>For sure you&#x27;d need an escape hatch, like Rust&#x27;s &quot;unsafe&quot;. And it would not be very useful around legacy libraries. But it would be tremendously useful if you could drop a block like<p><pre><code> neverthrows NullPointerError { ... } </code></pre> in your code and be sure that everything inside is null safe! I asked about this a few years ago on StackExchange [1] but so far I never heard about it anywhere else.<p>[1] <a href="https:&#x2F;&#x2F;softwareengineering.stackexchange.com&#x2F;questions&#x2F;349775&#x2F;different-kind-of-checked-exceptions-guarantee-to-only-throw-x" rel="nofollow">https:&#x2F;&#x2F;softwareengineering.stackexchange.com&#x2F;questions&#x2F;3497...</a>
评论 #24451658 未加载
评论 #24448967 未加载
评论 #24447535 未加载
iso8859-1over 4 years ago
The confusion regarding checked exceptions (which are fine, if not misused, see aazaa&#x27;s answer) was made much worse by IDE&#x27;s such as Eclipse, which would generate:<p><pre><code> catch (MyCheckedException e) { e.printStackTrace(); } </code></pre> This causes unreliable programs, since the programmer will initially only think about the successful path. Eventually, the exception will get thrown, and things will break in weird ways. They may not notice it quickly, because the stack trace will be buried in logs. Alternatively, if the IDE default has been<p><pre><code> throw new RuntimeException(e) </code></pre> or something similar, which would crash the program, the programmer would have noticed it more easily. Of course, the program would still be broken, but better crash hard and violently than subtly and confusingly.
评论 #24447562 未加载
grey-areaover 4 years ago
According to Gosling, including classes&#x2F;inheritance was his biggest regret.<p><i>I once attended a Java user group meeting where James Gosling (Java&#x27;s inventor) was the featured speaker. During the memorable Q&amp;A session, someone asked him: &quot;If you could do Java over again, what would you change?&quot; &quot;I&#x27;d leave out classes,&quot; he replied.</i><p><a href="https:&#x2F;&#x2F;www.infoworld.com&#x2F;article&#x2F;2073649&#x2F;why-extends-is-evil.html" rel="nofollow">https:&#x2F;&#x2F;www.infoworld.com&#x2F;article&#x2F;2073649&#x2F;why-extends-is-evi...</a>
pmcollinsover 4 years ago
Possibly unpopular opinion: Java&#x27;s biggest mistake, by far, was annotations that define behavior <i>at runtime</i>.<p>So now we have consultingware like Spring where if something isn&#x27;t working, it could because you missed an annotation somewhere, or put the right annotation in the wrong place. Which annotation? Where? Maybe you&#x27;ll find out a week from now that you made a mistake, when a customer finds a bug in production.<p>This took all of the compile-time checking goodness that you got from Java and threw it in the garbage. Now you either have to call an expensive consultancy, read books&#x2F;manuals about your gigantic framework (fun!), go on forums, etc. You can&#x27;t just use your coding skills.<p>I still often use Java for my side projects because I love it without runtime annotations, but thank god for the rise of Golang. I&#x27;d rather deliver pizza than go back to the misery that is annotation-driven development in Java.
评论 #24443988 未加载
评论 #24443945 未加载
评论 #24446017 未加载
评论 #24444088 未加载
评论 #24443802 未加载
crehnover 4 years ago
On a slight tangent, I&#x27;d rather have <i>only</i> checked exceptions, so I know exactly what might throw where. Instead, I have to rely on potentially outdated Javadoc and debugging runtime exceptions in production to find them.
评论 #24444548 未加载
评论 #24444344 未加载
评论 #24444659 未加载
hodgesrmover 4 years ago
If checked exceptions overall are Java&#x27;s biggest mistake, then the InterruptedException implementation in particular is the second.<p>It conflates thread management with exception handling in a way that&#x27;s difficult to understand and implement correctly. The relationship between InterruptedException and the Thread.isInterrupted() method is a particular pain point for coders.
评论 #24444194 未加载
评论 #24445074 未加载
josephcsibleover 4 years ago
I don&#x27;t think the whole concept of checked exceptions isn&#x27;t a mistake, although the way they&#x27;re implemented certainly is. In my experience, the problems with them almost always stem from one of two issues:<p>1. Built-in exceptions that are checked but should be unchecked, IOException being the main offender (I don&#x27;t mean things like FileNotFoundException; I mean the kind you can get if the OS returns -EIO)<p>2. Lack of exception polymorphism, preventing you from doing things like l.stream().filter(SomeClass::somePredicateThatMayThrow), even if the function that you&#x27;re doing it from can throw the same exception that the predicate can<p>I think checked exceptions would be great and nobody would hate them if those two problems were fixed.
kasperniover 4 years ago
This is still one of the pieces written on error handling. <a href="http:&#x2F;&#x2F;joeduffyblog.com&#x2F;2016&#x2F;02&#x2F;07&#x2F;the-error-model&#x2F;" rel="nofollow">http:&#x2F;&#x2F;joeduffyblog.com&#x2F;2016&#x2F;02&#x2F;07&#x2F;the-error-model&#x2F;</a>
pjmlpover 4 years ago
I sorely miss them in .NET, specially with libraries without any kind of documentation regarding the errors that they throw.<p>Also checked exception haters always overlook the fact that CLU, Modula-3 and C++ did it first.
评论 #24443937 未加载
评论 #24443700 未加载
评论 #24444330 未加载
评论 #24449199 未加载
mumblemumbleover 4 years ago
I&#x27;m a relative newcomer to Java, and, being a newcomer, I have put some effort into exploring as many corners of the language as I can. One that&#x27;s proven to be a particular puzzle is checked exceptions. But I think I finally understand them now.<p>I quickly found that checked exceptions just do not play nice with any sort of functional-style programming, like the article describes. But the problem goes so much deeper than that. Checked exceptions are also, as far as I can tell, incompatible with an object-oriented programming style. More or less for the same reason that they interact poorly with FP. The fundamental problem is that checked exceptions don&#x27;t really play nice with polymorphism or higher-order programming of any type.<p>Which takes us to the crux of how I understand them now: Checked exceptions may not go well with FP and OOP, but they make all the sense in the world if you&#x27;re doing procedural programming. There, you&#x27;re not trying to create deeply nested abstractions, and you&#x27;re not messing around (much) with polymorphism tricks. The code&#x27;s very lexically organized, with little in the way of dependency injection or higher-order programming. When you&#x27;re programming procedurally, it&#x27;s fine to be exposed to the implementation details of stuff further down on the call graph, because you&#x27;re the one who put it there in the first place.<p>And that, in turn, means that checked exceptions are not really a mistake. They&#x27;re just a piece of evolutionary history. Because, early on, Java wasn&#x27;t <i>really</i> an object-oriented language. It was a deeply procedural language with some object-oriented features. It arguably still is, it&#x27;s just that there&#x27;s been a big cultural shift toward trying to take a more object-oriented approach since Java 5 came along and made it more practical to do so.
评论 #24447934 未加载
crehnover 4 years ago
While we&#x27;re talking about terrible decisions, can you guess what the following code will print?<p><pre><code> String s = null; switch (s) { default: System.out.println(&quot;Hey&quot;); } </code></pre> Hint: it will throw NullPointerException.
评论 #24444594 未加载
评论 #24444399 未加载
jarymover 4 years ago
Mistake maybe but I disagree on the ‘biggest’ part.<p>For me type erasure is a bigger issue. I get that it was done for backwards compatibility but the drawbacks imposed by that decision seem to only grow as more time passes and more new compromises have to be made.
评论 #24444421 未加载
评论 #24444222 未加载
imglorpover 4 years ago
I just want to throw a plug for the concept of Railway Oriented Programming. It can be laid on top of almost any functional-ish language that can implement some sort of Result(Ok,Err) return type. And to the OP&#x27;s point, you can catch exceptions where they occur and `return Result(Err(details))`.<p>We applied ROP with great success at a fintech where we wanted to clean up a block of business logic with many failure paths. Instead of a forest of nested conditionals or try&#x2F;catch mess, there was a very simple happy path with clear handling for all the errors.<p>Here&#x27;s a good start. Ignore the language details, the concept is universal. <a href="https:&#x2F;&#x2F;fsharpforfunandprofit.com&#x2F;rop&#x2F;" rel="nofollow">https:&#x2F;&#x2F;fsharpforfunandprofit.com&#x2F;rop&#x2F;</a>
ben7799over 4 years ago
I&#x27;ve been using java since Pre-1.0 and professionally since 1999 and I don&#x27;t see checked exceptions as being particularly high up the list of java issues.<p>Even with all the functional stuff they almost never seem to really create a major issue.<p>My biggest issue with Java is just the way they&#x27;ve caved and constantly added new stuff that is always grafted on so it&#x27;s never quite as good as a language that focuses on that programming paradigm from the start.<p>But none of the problems in the language compare to the scale &amp; scope of the problems caused by Java&#x27;s default developer &amp; architect culture. The culture is terrible... everything gets overcomplicated, overabstracted, etc. and you&#x27;ve got charismatic charlatans convincing wide swaths of developers to misuse and abuse language features in ways that have made a lot of people hate the language and have produced a lot of buggy and hyper inefficient code.<p>Java itself doesn&#x27;t have to be bloated, slow, buggy, and a massive memory hog. But the java developer community has continually made decisions to structure their java software in a way that makes that the default condition of Java systems. The way the Java language constantly gets new giant features grafted on plays into this.. everyone jumps on the latest language addition and misuses it for a few years before they come to understand it. By the time it&#x27;s understood there&#x27;s something new to move onto and abuse.<p>Java became everything about C++ it was originally supposed to simplify.
评论 #24443710 未加载
评论 #24443916 未加载
评论 #24443963 未加载
评论 #24443708 未加载
adrianmonkover 4 years ago
There are two kinds of exceptions: (1) those that can (and should) be handled in a meaningful way, and (2) those there&#x27;s no way to handle and you should just crash.<p>A big part of the reason people hate checked exceptions is that actually doing #1 correctly is really damn hard. It&#x27;s a whole separate dimension of complexity that your design needs to tackle.<p>A compiler that checks exceptions forces you to do it. Abruptly, if you&#x27;re new to the language. It flips the floodlights on at full brightness and makes you see the full scope of the problem. It&#x27;s tempting to shoot the messenger.
Reason077over 4 years ago
The biggest mistakes in Java are checked exceptions, NullPointerException, and primitive types. But which one of these is the <i>worst</i> mistake really depends on your perspective, and the mood of the day.
评论 #24449266 未加载
devitover 4 years ago
Rust has a system equivalent to checked exceptions.<p>However Rust, unlike Java, has a great macro system and can thus easily generate higher level exceptions wrapping the lower level ones.
评论 #24445458 未加载
评论 #24444722 未加载
nayukiover 4 years ago
In my eyes, Java&#x27;s biggest mistake is that the byte type is signed instead of unsigned. Masking a signed byte with (b &amp; 0xFF) causes so much needless pain, and I have never wanted to use a signed byte. On the other hand, I appreciate that Java doesn&#x27;t have unsigned versions of every integer type; that simplifies things a lot. As for checked exceptions, I&#x27;m still undecided on whether they&#x27;re a good or bad thing.
评论 #24449217 未加载
samfisher83over 4 years ago
I liked checked exceptions. It makes you aware of what exceptions that might happen. Makes you think about how to handle it.
bcrosby95over 4 years ago
The biggest problem with checked exceptions is that the application writer decides what is a recoverable error. Not the library designer. I could easily imagine a program where SQLException is a recoverable error. But I don&#x27;t write those types of programs.
评论 #24443380 未加载
评论 #24443365 未加载
spionover 4 years ago
The sad bit about checked exceptions is that everyone compares any sort of error tracking to them and immediately dismisses many useful ideas<p>Java&#x27;s checked exceptions got the worst possible combination of error tracking. Its optional, so you don&#x27;t even get to see if a function throws (kind of like the billion dollar null mistake) and its based on classes, which means a lot of irrelevant names leaking throughout the codebase.<p>Like with nulls, the main value is being able to claim that a function doesn&#x27;t ever throw, at all. Apple&#x27;s Swift got this just right.<p>A simpler system of &quot;throws &#x2F; doesn&#x27;t throw&quot; and with optionally polymorphic variants &#x2F; unions to complement it would go much further.
flowerladover 4 years ago
The biggest mistake of C# is not having checked exceptions. Your carefully written program can crash because someone modified a dependency to throw a new exception. So the only way to make your program resilient against such changes is to catch the base Exception class, which everyone agrees is wrong (because of &quot;swallowed&quot; exceptions). In Java the compiler alerts you if someone modifies a dependency to throw a new exception, which is good.<p>See long discussion here: <a href="https:&#x2F;&#x2F;forum.dlang.org&#x2F;thread&#x2F;hxhjcchsulqejwxywfbn@forum.dlang.org" rel="nofollow">https:&#x2F;&#x2F;forum.dlang.org&#x2F;thread&#x2F;hxhjcchsulqejwxywfbn@forum.dl...</a>
评论 #24449252 未加载
noisy_boyover 4 years ago
I&#x27;ve found checked exceptions pretty useful. I can pass context-specific details to the exception and encapsulate the message formatting to the exception itself (helps if I&#x27;m throwing that in multiple places). They also allow me to decide the http return code based on the exception. E.g. using Spring Boot&#x27;s controller advise, I can map a group of exceptions to be user errors (say, bad request) and another group to be service errors (say, internal server error) etc and don&#x27;t have to worry about where the exception is being thrown from - it&#x27;ll return all the details with correct return code to the user.
CornCobsover 4 years ago
Having used Java somewhat, the biggest pain points I encountered with checked exceptions was their incompatibility with highly generic code (aka streams). What if all library functions taking lambdas (e.g. map, filter) all took throwing functions as parameters (i.e. have an extra generic X argument for the exception type, like R apply(T arg) throws X) and simply rethrew those exceptions, AND have the exceptionless functions (R apply(T arg)) be a subtype of the throwing version so they are compatible? I haven&#x27;t touched java in a while so I may have forgotten a thing or 2 about its type system
mcculleyover 4 years ago
I would prefer there were just a semantic way to find out what exceptions a method might throw. I develop a lot of Java and often end up just rethrowing a checked exception as RuntimeException or AssertionError.<p>A long time ago, I developed quite a lot of code in Ada83. Our team found having to use documentation to express what exceptions might be thrown led to many errors. I was pleased when Java came around that this was expressed directly in the function declaration.<p>But then it became clear that it lead to a lot of boilerplate.<p>I would like the throws keyword to just be an indication of what might be thrown and not require that I catch it.
jayd16over 4 years ago
I don&#x27;t mind Java checked exceptions but of the languages in this style I think I prefer C#&#x27;s Task type. It combines a promise with a simple IsFaulted boolean and a way to rethrow the caught exception at your discretion (or it will throw if you accidentally access the result getter).<p>You can use catch block style with typed exception handling or simple boolean checks depending on the situation and what you prefer.
tomohawkover 4 years ago
Java has checked exceptions, unchecked exceptions, and errors.<p>Some checked exceptions, such as InterruptedException, should really be something else. I&#x27;ve very rarely seen this exception handled properly by anyone. Often, a general catch Exception will also catch this, and while the code will work just fine in most circumstances, random threads will not go away when they should.<p>It&#x27;s a mess.
bitwizeover 4 years ago
Java&#x27;s biggest mistake was not including lambdas and generics from the very beginning. Checked exceptions are a feature because they force you to think about how you will handle exceptions: usually one of die, try again, or try something else. Forcing the programmer to make these decisions explicitly is a good thing.
评论 #24449300 未加载
mcguireover 4 years ago
If the exceptions thrown by your code aren&#x27;t part of the interface, then pretty much nothing is. That means strong typing is actually Java&#x27;s biggest mistake.<p>This isn&#x27;t to say that checked exceptions are always used well. (What exactly am I supposed to do about an exception from .close()?)
whitenoiceover 4 years ago
Most codebases use lombok, you can use @SneakyThrows or @SneakyThrows(SpecificException.class) - <a href="https:&#x2F;&#x2F;projectlombok.org&#x2F;features&#x2F;SneakyThrows" rel="nofollow">https:&#x2F;&#x2F;projectlombok.org&#x2F;features&#x2F;SneakyThrows</a>
srequeover 4 years ago
I&#x27;m surprised how controversial this is; checked exceptions are a mistake. There is a reason C#, Go Swift, Rust, Scala, etc. don&#x27;t have them, and it&#x27;s not because these language authors don&#x27;t know what they are doing.<p>Checked exceptions have all the disadvantages of monads:<p>* Checked exceptions don&#x27;t <i>compose</i> with each other. You have to create manual witnesses of composition (methods throwing multiple exception types, or wrapping exceptions into new exceptions like a monad transformer)<p>* Checked exceptions infect the type system, having to be copied everywhere.<p>However, they have none of the advantages of monads, and more disadvantages besides. Java the language does not provide any facilities for abstracting over checked exceptions, and they interact terribly with any design involving higher order functions or any other higher-level abstraction.<p>It&#x27;s time for the java community to admit they got this one wrong and move on.
评论 #24447597 未加载
desertloungerover 4 years ago
I write a lot of Java, and like checked exceptions. The problem is rather the opposite, basically all of the concrete exception classes that you might think to use (e.g. IllegalArgumentException) are unchecked!
ncmncmover 4 years ago
Sure and they are a big, big mistake, but biggest? I can name bigger ones. Default virtual is quite the whopper, for example.
评论 #24443539 未加载
评论 #24443603 未加载
评论 #24443658 未加载
评论 #24443531 未加载
评论 #24443571 未加载
评论 #24443546 未加载
franzwongover 4 years ago
I also see people saying they miss checked exception because developers always forget to check the returned error code...
storedboxover 4 years ago
Checked exceptions are hardly Java&#x27;s biggest mistake.
kanzenryu2over 4 years ago
It&#x27;s easy to see that checked exceptions are bad... no other language tried to copy the idea. A worthy experiment, but that&#x27;s all. What else did not get copied? Classloaders.
评论 #24448572 未加载
tealpodover 4 years ago
My biggest complaint with Java is Generics. I am not against Generics, I don&#x27;t like the way they were implmented in Java and they copy&#x2F;pasted the same shit to C#.