[funnymony]

> important failure that can't be dismissed

But importance of the failure is determined completely by the program, not the library.

Grep fails to open a file for reading -> message the user and exit

Nuclear reactor controller fails to read important a file -> initiate reactor shutdown or something.

If file read is critical, you have to handle failure no matter what the interface is. Because you know that disk can fail.

[invalidname]

Grep isn't a library. It's a program. Some things are important in the library level e.g. an SQL exception must have proper cleanup. However, in some cases you don't want to cleanup. You might want to try a different approach so generic cleanup code isn't necessarily the right thing.

E.g. in the case of grep. Say I wrote grep and want it to be generic. I wrote a library that implements grep. Then I write a grep GUI tool. OOps. It exits if the file isn't found instead of showing an error dialog. With exceptions this is communicated up the layers. That's their purpose.

If I'm writing generic code and that code is used in a nuclear reactor I would very much not like my failure code to decide what to do. That's why we have exceptions, they punt the responsibility to the next person up the chain. I have no idea how to initiate a nuclear reactor shutdown etc.

But as API authors how can we make sure the person who writes the code up the chain knows that this is something crucial?

[funnymony]

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

[invalidname]

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_74]

> 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.

[magicalhippo]

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.

[invalidname]

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.

[tremon]

But as an author if there's something important

You're still ignoring other people's point in this thread: you (the author of a library/package) cannot decide what is important for the users of your library. You can guess, but your guess will always be wrong for a subset of your downstream users.

And speaking from the other side, as an application developer: for most of my code, an ArrayIndexOutOfBoundsException is a pretty serious exception. How do I go about making it a checked exception?

[scarface_74]

When I’m using grep, it’s usually in the context of shell script. For all intents and purposes it’s a library.

I can choose to handle the error myself or let the shell script crash by having “set -e”.

Grep returns a non zero error code and it’s still up to me to decide how to handle it.

[invalidname]

That's your point of view. It's up to you. My experience is different and often deals with handles very large projects with serious continuous uptime. When you have dozens of developers committing to a project and using the APIs exiting with an error just isn't an option.

[scarface_74]

I did say

> I can choose to handle the error myself

[invalidname]

That's not a practical strategy in a large system. That's why we have exception handling.

When we write generic library code we have no way of knowing how to handle an error in the full system. We want to concentrate some of the error handling while still making localized decisions in various places.

E.g. I want metrics and observability details updated, yet I want locally to retry some behavior. Doing this every time there's an error would force every library and every part that can fail in my code to know how I plan to handle the error.

[scarface_74]

Isn’t that what I just said? It’s my responsibility as a consumer of the library to decide how to handle it?

[MrJohz]

But the point is that in both cases the failure needs to be handled somewhere and somehow. Surfacing the error might be a valid option, but to make the decision you need to know that the error is there in the first place.

This can be solved with good documentation, but it can also be solved in the type system. Typically, if I can get my computer to do work for me (e.g. make sure that I've handled all possible error cases) then I'm much more confident in my code, hence why I see a lot of value in a well-designed checked exceptions system.

[tadfisher]

Exceptions aren't normal parts of the type system though, they're a way to enforce control flow to deal with them. Another way to do this is with a Result type, which would actually be part of the same type system that you use in the rest of the language.

[MrJohz]

Why can't they be part of the type system? Rust is a good example of a case where they are part of the type system (albeit in a more monadic form). You've also got typed effects, where effects are essentially a generalised form of exception.

[rothron]

> But importance of the failure is determined completely by the program, not the library.

Exactly. I think this is the real crux about what's wrong with checked exceptions. It puts the responsibility to decide what exceptions are important on the library, where it doesn't belong. Only the user of the library knows that.

[joebiden2]

Isn't it exactly the opposite? Checked exceptions are for libraries to declare "exceptions" they can't handle themselves. You, the user of the library, have to deal with them (or declare them checked yourself¹).

I'm not a friend of checked exceptions myself, but I still think it's the opposite.

¹ which leads to the real issue with checked exceptions: they propagate through dependencies, if one nested dependency adds another checked exception, all dependencies have to add the exception or handle it themselves.

[rothron]

I don't think we disagree it's just a different perspective. The forced handling or propagation is what makes them annoying, but I think they're conceptually wrong.

It would be another matter if they were designed such that you could fix an issue and continue the call on the happy branch, but I suspect the cases where something like that would be applicable are very few.

[tremon]

Grep fails to open a file for reading -> message the user and exit

That should be: message the user and process the next file

[funnymony]

:)