undefined | Better HN

0 pointsfunnymony2y ago0 comments

Yes, grep and nuclear reactor controller, and your gui grep are applications.

They all use library for file reading.

As author of file reading library you don’t know how critical is the failure to open a file or how it should be handled. My point was that You know those things only at application level.

So it feels a bit misguided to decide at library level which failures are important. (I.e. which are checked vs which are unchecked)

> But as API authors how can we make sure

First thought: documentation. (which is required for both, checked and unchecked exceptions).

But overall, it’s not library author’s responsibility or ability to “ensure”. You can’t force correct handling of exception. At best one can make it a bit more annoying to ignore, and convenient to do the right thing.

My view:

- all exceptions should be unchecked

- assume all code throws

- if “log and exit/continue” is not enough and you need to know exact exception types, dig into the docs.

- read docs during lib version upgrades

0 comments

4 comments · 1 top-level

invalidname2y ago· 3 in thread

The library knows which are crucial issues that warrant your attention. A checked exception is a regular exception, it's just one that you can't miss and must either handle or propagate.

As a library author if you don't feel you need it then don't use it. It's optional. That's the beauty of it.

> First thought: documentation. (which is required for both, checked and unchecked exceptions).

Documentation < compiler checks.

> But overall, it’s not library author’s responsibility or ability to “ensure”.

Here we differ. Part of that is the domain we spend most of our time in. If you're giving me the example of grep then great, I see your point. Notice I'm giving an example of a high availability huge enterprise app.

Assuming all code throws forces overly defensive code which can cause a lot of problems. Yes, there's always a "catch all" but that's not a valid case for these sorts of apps.

Exit or continue are never enough for these sorts of applications.

We have dozens of dependencies and sometimes more. Some of them have mountains of documentations. Often we delay updates since these are enterprises. Going over 3 years of diffs in docs is just not a feasible option. Just the diffs in Spring Boot alone and all its dependencies would take several years.

scarface_742y ago

> The library knows which are crucial issues that warrant your attention

The library author can’t know what’s crucial in the context of my program.

magicalhippo2y ago

Indeed. For most applications, an out-of-memory exception is typically one that's not necessary to handle and just let it bubble to the top, as there's not much sensible you can do if you can't allocate a few hundred bytes for a new object.

However I've written several pieces of code where allocating a large buffer could fail but where this failure was not crucial. So I handled the out-of-memory exception and just moved on.

invalidname2y ago

This feels argumentative but fine.

If you're unsure then make it a runtime exception. I agree that a lot of the problems people have with checked exceptions is that people over use them.

You don't want to handle the checked exception wrap it with a runtime exception. But as an author if there's something important, I want to give the user of the library as much help as I can.

1 more reply

j / k navigate · click thread line to collapse