←back to thread

Software development topics I've changed my mind on

(chriskiehl.com)
873 points belter | 3 comments | 05 Feb 25 09:50 UTC | HN request time: 0.652s | source
Show context
Terr_ ◴[05 Feb 25 10:33 UTC] No.42946597[source]▶
> Java is a great language because it's boring [...] Types are assertions we make about the world

This is less of a mind-was-changed case and more just controversial, but... Checked Exceptions were a fundamentally good idea. They just needed some syntactic sugar to help redirect certain developers into less self-destructive ways of procrastinating on proper error handling.

In brief for non-Java folks: Checked Exceptions are a subset of all Exceptions. To throw them, they must be part of the function's type signature. To call that function, the caller code must make some kind of decision about what to do when that Checked Exception arrives. [0] It's basically another return type for the method, married with the conventions and flow-control features of Exceptions.

[0] Ex: Let it bubble up unimpeded, adding it to your own function signature; catch it and wrap it in your own exception with a type more appropriate to the layer of abstraction; catch it and log it; catch it and ignore it... Alas, many caught it and wrapped it in a generic RuntimeException.

replies(13): >>42946899 #>>42946979 #>>42947054 #>>42947147 #>>42947485 #>>42947568 #>>42948130 #>>42948153 #>>42948666 #>>42951688 #>>42952999 #>>42953957 #>>42984777 #
dustingetz ◴[05 Feb 25 11:12 UTC] No.42946899[source]▶
remind me why they don’t work? because “throws Exception” propagates virally to every method in the codebase?
replies(3): >>42947046 #>>42948691 #>>42949347 #
rad_gruchalski ◴[05 Feb 25 11:29 UTC] No.42947046[source]▶
Well, if you don’t handle them then… yes? What else can be done?
replies(1): >>42947285 #
1. karatinversion ◴[05 Feb 25 11:58 UTC] No.42947285[source]▶
There's also the fact that common methods threw exception types that were not final, and in fact overly generic. If I call a method that declares itself to throw NoSuchFileException or DirectoryNotEmptyException, I can have a pretty good idea what I might do about it. If it throws IOException without elaboration, on the other hand...
replies(1): >>42947453 #
2. jkrejcha ◴[05 Feb 25 12:18 UTC] No.42947453[source]▶
With regards to I/O, there are generally any number of weird errors you can run into, file not found, directory exists, host unreachable, permission denied, file corrupt, etc etc. Like anything file related will be able to throw any of those exceptions at almost any point in time.

I think IOException (or maybe FileSystemException) is probably the best you can do in a lot of I/O cases unless you can dedicate time to handling each of those specially (and there's often not a lot much more you can do except for saying "Access is denied" or "File not found" to the user or by logging it somewhere).

replies(1): >>42950220 #
3. bluGill ◴[05 Feb 25 15:49 UTC] No.42950220[source]▶
There are fatal IO errors and non-fatal. Most of us don't care about the non-fatal case, but mainframes have the concept of "file isn't available now, load tape 12345", "file is being restored from backup, try again tomorrow" - things that your code could handle (if nothing else you should inform the user that this will take a while). There is also the "read off the end of the file" exception which in some languages is the idiomatic way to tell when you have read the whole file.

But most IO errors are fatal. It doesn't matter if the filename is not found, or the controller had too many errors talking to the drive and gave up - either way your code can do nothing.