Right. What I mean is that when you can't handle an exception and you should rightfully become unchecked it's extremely verbose. For example if I'm reading a config file and I should rightfully panic and crash my program if that file doesn't exist:

    Config config;
    try {
       config = readConfig("/some/path/to/a/file/that/must/exist.txt")
    } catch (IOException ex) {
       throw new RuntimeException(ex);
    }
    
    doSomeStuffWith(config);

Realistically situations like this should be:

    Config config = readConfig!!!("/some/path.txt"); // !!! being some operator that says "shut up compiler crash if this happens"
    doStuffWith(config);

People do not like checked exceptions because they either need to check and colour the whole stack or write way too much code to panic.

It is not very common to run in to an error that should crash the application. If you have to write a bit of code to do that, in my opinion that's fine.

I'm just going to say that you're opinion is wrong. You're opinion is the reason that the majority of errors in C#, Java, JavaScript, Dart, D, and all the other languages that use exceptions have decided that all errors should crash the application and that you won't know about what can error.

Programmers are LAZY. Making them do verbose things when they can't possibly handle it are going to cause them to reject the language feature.