Timeline for The case against checked exceptions
Current License: CC BY-SA 3.0
14 events
| when toggle format | what | by | license | comment | |
|---|---|---|---|---|---|
| Feb 21, 2024 at 17:06 | comment | added | Holger | Performing the I/O in the event handling thread is the opposite of what these APIs were designed for. Likewise, implementing “a list that is backed by a database or a filesystem” and putting it into algorithms designed for local storage structures is a really bad idea. But indeed, when you do such horrible things, Java’s code looks more complicated and because some developers will do it anyway, it makes Java a bad language… | |
| Jul 11, 2017 at 4:44 | comment | added | aioobe | ... So, in this case I'd actually claim that the checked exceptions in fact helped you write more responsible code. The InvocationTargetException is nothing but unfortunate. It should clearly have been a RuntimeException. It's from the early days of Java, and no one had experienced the annoyance checked exceptions had brought us today. I would however like to emphasize that this is an API design issue, rather than an issue with checked exceptions as a language feature. Is it hard to get right? Sure, sometimes. But not so hard that a good feature like this should be tossed out the window. | |
| Jul 11, 2017 at 4:39 | comment | added | aioobe | I think this answer hits the head on the nail. "Look how crufty the Java code becomes. Java is already verbose!" A few remarks though: Just rethrowing the IOExceptions and InterruptedExceptions and crash and burn like that is a bad idea. In 9 cases out of 10, there's a more responsible way of dealing with the situation than to sweep it under the carpet. Where to deal with it? You're doing UI stuff here, so here's the right place to do it! If you do this improvement in both snippets, the C# version starts to approach the Java version. ... | |
| Jul 10, 2017 at 18:15 | history | edited | aioobe | CC BY-SA 3.0 | deleted 264 characters in body |
| Apr 4, 2013 at 10:52 | comment | added | Francois Bourgeois | @TofuBeer Isn't being forced to update your code after the interface of an underlaying API changed a good thing? If you had had only unchecked exceptions there, you'd have ended up with a broken/incomplete program without knowing it. | |
| Mar 11, 2012 at 4:45 | history | edited | Luke Quinane | CC BY-SA 3.0 | decrease? yep :) |
| Aug 23, 2011 at 6:36 | comment | added | Mister Smith | You are mixing things here. C# is more recent than Java and has a simpler design for the every day tasks. You can achieve the same clean design in Java, adding your own libraries or utilities. | |
| Nov 15, 2009 at 9:53 | comment | added | neo2862 | Did you mean decrease the signal-to-noise ratio? | |
| Apr 2, 2009 at 16:38 | comment | added | TofuBeer | We are getting there :-) So with each new release of an API you have to comb through all your calls and look for any new exceptions that might happen? The can easily happen with internal to a company APIs since they don't have to worry about backwards compatibility. | |
| Apr 1, 2009 at 23:58 | comment | added | Luke Quinane | The known exceptions are put into the C# "Javadoc"; good APIs will define all known exceptions this way. You may be able to catch a FileNotFound inside run() but some exceptions can't be handled there. Catching them inside run() but not properly handling isn't good. Perhaps I'm misunderstanding. | |
| Apr 1, 2009 at 15:36 | comment | added | TofuBeer | And in the C# way how do I know that the I/O exception can occur? Also I would never throw an exception from run... I consider that abusing exception handling. Sorry but for that part of your code I just can see your side of it yet. | |
| Apr 1, 2009 at 4:25 | comment | added | Luke Quinane | In the example both Java and C# are just letting the exceptions propagate up without handling them (Java via IllegalStateException). The difference is that you may want to handle a FileNotFoundException but its unlikely that handling InvocationTargetException or InterruptedException will be useful. | |
| Apr 1, 2009 at 3:46 | comment | added | TofuBeer | Update UI from non UI-thread in C#: - what if an exception occurs? | |
| Apr 1, 2009 at 3:25 | history | answered | Luke Quinane | CC BY-SA 2.5 |