Checked exceptions: Java’s biggest mistake (2014) (opens in new tab)

I conjecture that much of the legitimate pain from checked exceptions in Java were because the language to talk about exceptions was so limited.

For instance, consider fold or map functions. There was no way of saying "this might throw anything that might throw", so the only option was "this won't throw anything and that cannot throw anything" or "this might throw anything".

Without the necessary flexibility, developers aren't "forced" to consider only error paths but also manifold impossible paths that aren't easily distinguished from legitimate error paths.

Kotlin has no mechanism to force error handling. You may suggest that we use sealed classes as return values and match on them, which is okay-ish, but suffers from two big issues:

1. You are not forced to use the result, so if you call a function for its side effects, the compiler will not warn you that you should unwrap the value. Rust and Swift do not have this issue.

2. This is extremely tedious, as you mention. But it's specific to Kotlin and not generally true as you later suggest. Haskell had monad comprehension (do notation), Scala has the same thing, Rust has the ? operator.

Also, regarding Kotlin; no library, nor the standard library, does anything other than throw unchecked exceptions on all kinds of failures. Kotlin is a step backwards, IMO.

Also PHP has checked exceptions, like Java.

You are not forced per se, and can have the same level of obsfucation. It's pretty common to find code ignoring exceptions or wrapping them in RuntimeExceptions, like:

  try {} catch (Exception e) {
    throw new RuntimeException(e);
  }

Also not doing nothing, or the famous catch and log

Not sure if Rust counts as mainstream by your metric, but it does have compiler enforced error handling in the form of the Result sum type.

> compiler enforced error checking. Very, very few languages have that

  __attribute__ ((warn_unused_result))

in C/C++ with GCC and Clang is great.

Avoiding the “boilerplate” of error handling means that you have implicitly coupled code now. Exceptions make local reasoning not possible. I guess you may want that in a small minority of cases, but I don’t understand the benefit they give you overall. It’s just a shortcut and a hack, and I’d rather see explicit control flow 100% of the time.

> in most cases I have no idea how to recover from error: just keep throwing it to the caller until someone knows what to do. I want it to be the default behavior and I don't want to clutter my code with all the catch-wrap-rethrow boilerplate.

What's your alternative? Using return values? But then you are doing the bubbling, manually.

Exceptions offer a more elegant and less boiler plate approach to this problem: if your code can't handle an exception, just declare it in your signature and ignore it. This is really the best approach to this problem:

- The error cases are part of the function's signature (as they should). - The language takes care of bringing the exception to the right handler. - Your code can proceed with the assumption that all the values are sound.

Unchecked exceptions were intended for problems that your code shouldn't really be expected to handle; catching them at the top-level, reporting the error, and letting the user figure out what to is about the only reasonable answer.

Checked exceptions are part of your API, things that your code should be dealing with, and catch-wrap-rethrow is often the right thing. It only becomes a problem with Java programmer's tendency towards thin, shallow abstractions.

> there are always unchecked exceptions

I’m not sure this is necessarily true.

There are always unchecked Throwable’s, but exceptions and Errors are quite distinct things.

Perhaps because the complexity budget of trying to get checked exceptions right is so high that no one even bothers to try. Once you find yourself able to just return values representing an ADT, then why bother? If the point of a checked exception is that the caller should try handling it immediately, then just return a value like IO<T> instead of return T but maybe throw IOException.

> A perfect example is a missing element in a remote system. An old api would throw some sort of a Element Not Found Exception.

Wait, if the example involves a remote system how can the Exception be the bottleneck? Even generating the completely optional stacktrace shouldn't take that much time.

Exceptions are slow to throw, but they're meant to be exceptional so that's OK. Good implementations impose no overhead the rest of the time. This is not the case for return type based systems, where you can easily end up with an allocation that must be GCd later.

Not as slow as many people think, especially with things like OmitStackTraceInFastThrow

Kotlin made the worst mistake here. At least Scala actually gives you ways to do error handling somewhat ergonomically with for comprehensions. Kotlin gives us nothing. Sure, you're "supposed" to return sealed classes and match on them. But it's so tedious and non-obvious that I've literally never seen it done in any Kotlin code I've depended on.

They're so similar you can easily translate between the two e.g. https://github.com/unruly/control/blob/master/src/test/java/...

> For example, `Either[T, Either[FileNotFoundCheckedException, RuntimeException]]` is basically isomorphic to a function that returns T or throws and has the same monad support, but can still force the developer to handle the checked exceptions.

Yes, and I tend to write my code this way (although I find right-biased 'Either' a bit cleaner). The problem is (a) the mountain of JVM code which uses checked exceptions instead plus (b) the Scala compiler completely ignoring that exception information. Solving (a) is unrealistic, but (b) is an entirely self-imposed decision by the Scala developers. Their type checker could have incorporated checked exceptions in exactly the way you describe, and I wouldn't have any complaints (about exceptions, at least... null is a whole different beast ;) )

There are three possibilities:

                         | Polymorphic exceptions | Monomorphic exceptions
    ---------------------+------------------------+------------------------
      Checked exceptions | Unsupported            | Java
    ---------------------+-------------------------------------------------
    Unchecked exceptions |                      Scala

If exceptions are unchecked then there is no difference between "inner" code and "outermost" code; the compiler cannot tell us that a handler is needed/missing. This is the case in Scala. The advantage is that we can compose code which throws and which doesn't throw (this is essentially dynamic typing for exceptions).

If exceptions are checked then there is a difference between "inner" code and "outermost" code: the inner code has 'throws Foo' annotations, the "outermost" code doesn't. The compiler will spot missing handlers (i.e. when our outermost code can throw). There are two ways this could be done:

If checked exceptions aren't polymorphic then we need to make multiple versions of higher-order functions, like List::map: one version which doesn't throw, one which can throw one exception, one which can throw two exceptions, etc. (these exceptions can be kept generic, but the number of them must be explicit). For example if we have a lambda which can throw KeyNotFound we can't use it with the standard List::map method, since that only accepts lambdas which don't throw. We could make an alternative method 'public List<B> mapE(FunctionE<A, B, E> f) throws E', but that wouldn't work for lambdas which can throw FileNotFound and PermissionDenied; we could write a 'public List<B> mapEE(FunctionEE<A, B, E1, E2> f) throws E1, E2', but that wouldn't work for three exceptions, and so on. AFAIK this is the current situation in Java.

If checked exceptions could be polymorphic, similar to row polymorphism ( https://en.wikipedia.org/wiki/Row_polymorphism ) or algebraic effect systems ( http://lambda-the-ultimate.org/taxonomy/term/35 ), then we would have the best of both worlds. In this setup the 'E' in an annotation like 'throws E' doesn't stand for a name, but for a set of names. Higher-order functions like 'map' can throw the same set of exceptions as the lambda they're given, and that set could have any size: if the lambda can't throw any exceptions then map's set of exceptions is empty; if it can throw five types of exception then map's set of exceptions contains those five; and so on. This is becomes even clearer for things like function composition:

    public Function<A, C> compose(Function<B, C> f, Function<A, B> g)

If 'f' can throw something from set E1 and 'g' can throw something from set E2, then 'compose(f, g)' can throw something from set E1∪E2. Likewise if something can throw E1 and we have handlers for E2, then the result can throw E1 \ E2.

AFAIK the JVM can't do this, nor can those languages which typically target it (Java, Scala, Kotlin, etc.; Idris has algebraic effects and it can run on the JVM, although it's not the standard target)

Unchecked exceptions are the worst of both worlds: you can call a function that will throw an exception that you could recover from but you have no idea, so you don't even know you should catch it.

At least, Either/Option force your code to take errors into account.

You still have to bubble them up and compose them manually, though, which is why checked exceptions shine.

> You're too far from the cause of the exception to do anything specific with it, the context is lost.

Which is perfectly fine. If you _can_ handle the exception near where it happened, do so. Otherwise bubble it up and log it or whatever.

Consider a REST service. If a DB or other error happens, I can retry right then and there if business logic calls for it (probably not), or just kick the can down the road where something appropriate like a 500 response serializer will take care of it. That’s a great pattern in my opinion.

> If you're handling errors far away... the context is lost. So the effort to transport the exception type throughout the call graph is pointless.

I get what you're saying, and things like 'Try[T]' lose the specifics of the error type too (we just get a 'Failure(Throwable)').

My problem occurs earlier on: which code might throw exceptions, and why? Java's checked exceptions let methods declare "I can fail with an AccessDenied error (along with all the usual stuff like NullPointerException, etc.)", and the compiler will make sure that's handled somewhere (even if it's just a log and quit).

Unchecked exceptions are implicit; the signatures don't tell us they exist, and the compiler doesn't check that they're handled. This makes sense as a last resort, for things like OutOfMemory (although Zig would disagree!); but in general it's unhelpful and dangerous. I think it's a poor choice on Scala's behalf to treat all exceptions this way. Their only redeeming feature is short-term convenience; it's essentially an instance of static versus dynamic typing. "Exception polymorphism" (which I imagine would look something like row polymorphism) would make checked exceptions more convenient, since we wouldn't need exception-specific boilerplate, and this might be enough to solve the problem.

Maybe the JVM might gain such a feature in the future, but until then we can use 'Either' or 'Try' to achieve a similar thing: they show us explicitly which methods can fail (answering the question in my second paragraph), and they force us (via the type checker) to handle the error case somewhere (even if that's just a generic log+quit handler at the top level, as you say).

So you're saying checked exceptions are perfectly fine.

I'll write my library code with checked exceptions. You call my library code in one of your methods. The compiler tells you to do something about the possible failure. If you want to handle it there, you handle it with a try{}catch{}. If you don't, you wrap it in a RuntimeException and rethrow it so your top level handler can deal with it.

Perfect.

Unchecked exceptions make it easy to fuck up the case where you actually might want to handle it close to the call.

`Result<T, dyn Error>` from Rust (since I'm not a Haskeler) is a result that can contain any error. Which is exactly what unchecked exceptions are.

Rust developers can fluently switch and convert between conrete `Result<T, SomeErrorEnumeration>` and `Result<T, dyn Error>`. It works beautifully. Libraries usually enumerate their errors (leafs), applications usually just throw everything to one universal error bag.

I think you're making a good point here if you look at it as an application developer. In my experience, checked exceptions are helpful when using a library. Would you recommend this approach for libraries as well or do checked exceptions have more of a role to play there?

> It seems strange to suggest there is recovery from that (beyond choosing another file).

That's the thing though, right? If you're writing a program with a UI you want to pop up a box saying "File not found, choose another".

A server program might format an appropriate response, log it and send it back to the client.

A batch process may just want to bail with a code.

So it would seem to make sense to have it checked...

People hate them because they want to quickly write unreliable software but are using a language designed for building reliable software

> The argument is that an error that can be recovered from isn't an exception. It should handled with standard guards (bounds check, null check, format check, etc). There's no checked exception that can't be better solved with an if/then statement.

That's a philosophical position that is largely driven by the language (and I suppose the ecosystem around it). I happen to agree with that position, so I prefer languages like rust and go over java.

But I also know that if I try to fight the customs of the language I'm working in, it'll end in a lot of pain and unnecessary angst; so, if I find myself using Java, I grit my teeth and used checked exceptions.

Why should all the callers have to redundantly implement all the validity checks instead of implementing them once in the callee and reporting the result?

That's as demonic as "assert" silently doing nothing by default.

The new source generators in C# 9 seem like a good compromise. Rather than rewriting code they can only add code but that ensures some amount of predictability.

https://github.com/dotnet/roslyn/blob/master/docs/features/s...

Is it though?

Why not just use code (generated if required) to read xml or json for each class? That way it is clear, in the source code and can perform other transformations as required.

> inject

I see the problem.

The whole point of spring XML was so you didn't have to "write code" to wire things up. Now we're using annotations to replace XML - we're writing code so we don't have to write code. It makes no fucking sense.

Annotation injections are a completely ridiculous turn of events.

Is turning Java into a dynamic programming language really the way to go to fix this, though?

Annotations are great as long as the consuming framework reflects the annotations exactly once for JIT/bookkeeping. Often the people I see who hate annotations are invoking reflection (explicitly or implicitly) in critical code paths.

Not thinking about the design of the language is a necessary adaptation for Java coders; the cognitive dissonance would be debilitating.

The reasoning goes stepwise.

1. In a good design, a class interface represents an abstraction. The public interface provides access at the level of the abstraction, obscuring details of implementation.

2. If it is a good abstraction, by definition it maps the public view to an internal model that differs from the public view.

3. Inheritors provide different implementations of the abstraction by defining their own versions of inherited virtual-function signatures, operating on the internal, abstracted model.

4. Because these virtual functions operate on the implementation, they should not be exposed to the client. Exposing them would violate the abstraction, exposing the internal model.

5. The public members of the base class translate abstract operations to operations on the internal model, and call virtual functions that provide variable concrete operations on it.

6. Therefore, it is wrong for the public members of the base class to be virtual: their interface is the public view of the abstraction. It is their job to map that view to the internal model, and to call the virtual functions that implement the model.

7. Similarly, it is wrong for the virtual functions to be public, because they implement the internal model. Making them public would expose it.

All that said, since Java offers only one organizing mechanism, the class, it necessarily gets used for everything, and not just for well-designed abstractions. It is not wrong to treat language features as a pot of mechanisms, and use them in ways that do not match their designed intent. Coding Java, there is no choice about it; classes are all you have, so you use them for everything, and the well-designed abstraction may be a rarity among all the other uses, and might not exist at all in many programs.

But Java's limited feature set is out of scope for discussion of the designed purpose of virtual functions. Used according to the Object Oriented model, public virtual functions are an oxymoron. But as mechanism, they are as usable as any other, if they work.

The sibling comments are talking about performance, but there's also a conceptual disadvantage to overriding.

There are two different ways to create a subclass in OOP. Java treats the subclass and the superclass as the same object. If the subclass calls a method on itself, it may go to the superclass first. This is a valid way to do things, but it can be dangerous and confusing.

Another way to create a subclass is to create two objects: the superclass and the subclass. The subclass has a reference to the superclass, but they are not the same object. If the subclass doesn't override one of the superclass's methods, then it implicitly proxies the method call to the superclass. If the superclass calls a method on itself, then it goes to itself rather than the subclass.

The difference between the two approaches is whether you want your class implementation to be open to extension (monkey-patching). Allowing class inheritance (Java's approach with the virtual methods) means that subclasses can override methods you define. It can be convenient, but it can also be a foot-gun. Class composition (proxies) prevents monkey-patching by subclasses.

If you know that a method isn't virtual, calling that method is just a function call with an extra argument for 'this'. If it's virtual, you have to look it up in a vtable, probably dereferencing two pointers in the process and making it harder on your instruction fetcher.

Java makes a lot of common classes final (e.g. String and Optional) so that it can avoid this. As I understand it, it's also got a lot of pixie dust to predict this some of the time, but then you can't rely on it.

Yes that's the benefit.

One downside is that every method now requires following a pointer, which is pretty awful for performance on modern hardware.

You can create non-virtual methods in Java, just make them final.

If you don't care about exceptions just put,

try { //your code } catch (Exception e) { throw new RuntimeException(e); }

around it and you'll be fine.

The thing about Java is that the code lasts for a really long time because when it fails, it does so usually with an exception that points to the problem. When promises hang in NodeJS or memory corruption happens in C, it's much more annoying to track down problems.

Then just wrap them in RuntimeException and rethrow them.

I mean, why are you writing a kleenex program in Java? Do you not want to declare a return type for your functions either? Java's checked exceptions are just a way to return multiple types from your methods: a success value and a failure values.

> let's say I'm writing a kleenex program to explore some feature. Not nice if you make me feel all kind of boilerplate.

Use Groovy. Seriously, you can code it up with zero boilerplate, use the REPL, notebooks, etc to get your idea into shape, all with 100% interop with your Java libraries.

When you are done, if parts of it should graduate to "real code", you can pretty easily port it over or keep parts of it in Groovy and just take the elements over that need to be Java for robustness, etc.

This is actually my standard workflow in development now.

It has been a while since I touch Java, but I thought you could just add `throws Exception` to `main` if you don't care about error?

I've never heard the term "kleenex program", what does that mean?

I don't think a language like Java should be optimized for exploration code, it should be optimized for long lived codebases that want to maintain stability and quality.

I'd also disagree that adding a throws to the signature is much boilerplate at all. Especially in the ages of IDE's

I think this feeds into my pet peeve that program source code shouldn't be text. The need to have everything spelled out in a readable fashion in text files is a major facilitator of boiler plate code in many situations (like long throws statements in Java). More semantic representations of source code have the potential to be more selective in their handling and display of such things. There would be more ways to show automatically deduced information or to filter out code/information that is irrelevant right now.

You can ... ?

Handle some, declare the method throws the others?

Don't get me wrong this is bad, but Java projects are littered with checks for logically but not technically unreachable code.

This is one of those things that should have never been done with exceptions, I'm looking at you Python, but with Maybe. Then you can either handle the None case or prove to the compiler that it's impossible.

Defending unchecked exceptions with bad iterator interface design is a little weird.

`next()` should return an option that you can `map` over.

`OutOfMemoryError` is the root of unchecked exceptions, you can't put it everywhere because then it might as well be nowhere.

Rust improves on this by using a different syntax for unchecked exceptions (`panic!` vs `Result`) which provides the benefit of discouraging unchecked without preventing it.

The concept was the same, though.

And they were the inspiration for Java's.

Have you missed the "specially with libraries without any kind of documentation" part of the sentence?

> In order to tests classes in isolation like this, all dependencies must be injected, so they can be stubbed or mocked.

This really boils down to which school of testing you follow. London (Mockist) vs Detroit/Chicago (Classicist). [0] is a good article on the different views of testing. Made me think more about it.

I find that using fewer mocks, and unit tests that integrate many classes (vs one set of tests for each class) makes Java programming more fun- but it is very much a Detroit school way. And that's okay, but it's good to really think about the differences.

[0]https://medium.com/@adrianbooth/test-driven-development-wars...

> AOP, interceptors, automatic transactions, all manner of magic

Magic stuff like this makes maintenance a nightmare. All these random attributes turn regular code into a 4d jigsaw puzzle - the complexity OP is talking about.

I think most of C++'s additions have avoided these problems in the way Java ran into.

C++ is pretty clear on the right way to do things at a given point in time. You will run into a similar problem when working with old code, you need to decide whether to abandon the new features to stay consistent, rewrite your program to make it consistent and new or do something in between and be inconsistent.

The problem with C++ is that the prevalence of macros and #include make backwards compatibility effectively impossible to patch around.

So you end up having to support ancient C++ code working as it was written decades ago working exactly the same. You can't even use file level flags because the object file in almost every case is going to #include old code.

The compiler can't stop you from doing things the wrong way due to this. You could have other tooling that warns you that your code is making X mistake but the compiler can't enforce that or assume that you don't make that mistake due to this extreme backwards compatibility requirement.

Side note: backwards compatibility in C++ is great and fundamental as it prevents fragmentation of the language between different incompatible dialects. The requirement alone doesn't fundamentally cause C++'s problems it just eliminates the easiest way to solve them. (Assuming Python 3 was easy)

Performance is why you should use different implementation details on the metal. The reason why there's a distinction at the language level, though, is because Java's designers chose to leak implementation details into the language's high-level semantics.

This distinction wasn't such a big deal in 1995. It was perhaps even the preferred way of doing things according to contemporary values. Nowadays, though, Java is a very different language that lives in a very different cultural milieu. So, nowadays, the language-level distinction, in combination with some other design decisions that came later, is absolutely a source of performance problems. Any code that tries to do things like store numbers in one of the standard collection classes will quickly devolve into a horrible mess of memory overhead and pointer chasing. It's led to this perverse situation where it's honestly not too hard to beat Java performance in a dynamically typed language like Clojure or Python, simply because dynamic languages make it easy to encapsulate the implementation details (and therefore to choose a more performant run-time implementation) in a way that Java's type system doesn't really allow.

You can still keep Java toward the top of the well-known performance benchmark leaderboards, but only by coding as if Java 5 never happened. Which is an option that's only tenable for toy use cases like benchmarks.

>This irks me too. It's been a while but I believe the workaround is just to define your own (checked) FunctionE, SupplierE, ConsumerE functional interfaces. But maybe that causes other problems I've forgotten.

You can do that, but you need to do it for every exception type ): I'd love it if Java had templated exceptions.

>> the stupid distinction between primitive types and Objects

One of the slowest things I found out about C# was floats being objects and `a < b` (or something similar) being a stack about 7 levels deep.

Yes, objects have the cruft and primitives don't. So you use primitive types whenever you can, including mathematical operations (unless the numbers are big and you need a BigInteger or BigDecimal, but that's another story). So far so good. But then, because of type erasure, collections (and literally anything generic except arrays) only accept objects, meaning that if you need a set of longs, you use a set of Longs instead. And if you are using some complex algorithm that relies on maps or sets of primitive collections, where you are constantly adding or removing elements, boxing and unboxing will kill your performance. I have been hit by this more than once. The last time I measured this (about half a year ago, which was the last time I encountered this in my job), the difference in memory usage was several Gb, and in particular there were about 7Gb used just for the Long class.

There are third party libraries that alleviate this. I use koloboke a lot, for example (which works for maps and sets, but lacks sorted collections and multimaps, which I also need to use very often); but the problem remains for anything slightly complex, and it's not uncommon to find yourself writing two almost identical copies of a relatively complicated method or class, one for objects and another one for ints (and maybe a third one for longs, a fourth one for floats...), because otherwise you hit the same problem.

So yeah. Primitive types are not objects and that limits them because Java doesn't work well with things that are not objects. C++ is much better in this sense, because generic code is actually generic and any type will do.

Wrapping exceptions when re-throwing can be really useful. I think that this feature is often underused, especially by people who complain about checked exceptions.

Call site vs use site is a great dichotomy for this discussion.

My position is that the caller decides how to deal with exceptions. When I'm adding a new operation to my web app, I won't add any exception handling at all. Why would I? There's a central exception handler in my app, which will log exception, analyze its type and return an appropriate status code to the caller (e.g. 500 or 400). If there's a kind of failure my centralized handler doesn't handle correctly, I'll add an explicit handler in the new operation, which would do the right thing in some cases, while the rest of issues are handled centrally still.

Checked exceptions make me have dummy handlers all over the place.

Yeah it's reasonably common for people to try and salvage checked exceptions by saying people are doing them wrong but at some point you realize the best you're doing is trying to put lipstick on a pig.

Here's a bigger problem: checked exceptions pollute your API and expose implementation details. Consider an API that stores and retrieves objects. A particular implementation does so by writing them to a database via JDBC so you get SQLExceptions. You have two basic approaches:

1. Include SQLException in your function signatures so the caller can deal with it. This exposes the implementation detail; or

2. You can hide it by transforming that checked exception into something specified for your API. At this point, what benefit have you gained from SQLException being a checked exception? You're hiding that detail.

For (1), you're baking checked exceptions into your function signatures such that it can be really difficult to change later on.

If you sit down and think about the practicalities the argued upsides of checked exceptions are essentially nonexistent and unchecked exceptions are actually strictly superior.

Here's another pattern that happens with checked exceptions in Java:

    try {
      doSomeSQL();
    } catch (SQLException e) {
      // do nothing
    }

You will see people do this all the time because they don't want to deal with the checked exceptions. A better catch-clause is:

    throw new RuntimeException(e);

You can argue people shouldn't do the first and they shouldn't but unchecked exceptions will simply bubble up unless you deliberately swallow it. That's a way better default. Defaults matter.

> checked excpetions should only be exceptions that a developer COULD handle and not ones that he can't

And that's kinda the problem; you can declare the ones a user MIGHT be able to recover from, but there's still the chance of unrecoverable or unforseen errors, so you wind up declaring THROWS EXCEPTION anyway...

> in C# the library designers usually create a "Result" object that has a boolean of succeded or status of enum instead of using exceptions for failures. i.e. most i/o errors are not recoverable, thus c# does not enforce you to recover from them.

Depends on the operation but yes. Either There's a Try___ Pattern (where boolean is result, and 'out' parameter from method is your parsed value) or some will do an enumeration pattern.

Still, I'm a fan of Option for these sorts of things nowadays...

I fucking hate SQLException. It's a giant pain in the ass to dissect it to figure out if it's an error because the database exploded, or because I made a syntax error, or because something real failed like a uniqueness or foreign key violation.

> - protocol exceptions like duplicated key

> - query exceptions

Even that is just barely scratching the surface. Postgres has ~250 error codes, and while not all of them can be triggered by all operations or statements, there's way more granularity in there than there is in just two piddly exceptions.

> Caller can add a throws declaration themselves and catch anything.

You are right. I meant someone in the call stack has to catch, not the immediate caller.

That I mentioned null pointers is a red herring. I want to add a block that tells the compiler "prove that no exceptions (checked or unchecked, not even NPE)" can escape outside of this block!".

The escape hatch is about this: imagine you have a function that throws if the argument is odd, but you know you will only call it with an even number:

    void myFunc(int i) never_throws {
        swear_never_throws(NumberOddException) {
            throwsIfOdd(i*2);
        }
    }

(Apologies for the pseudo-code, I haven't made up a nice syntax.) If you mark your function that no exception can escape (not even an unchecked exception!), but the compiler sees that throwsIfOdd can throw NumberOddException, you must of course assert that what you are doing is OK.

If you use try/catch, you can either swallow the exception, deal with it, or rethrow. But sometimes you don't know how to handle or rethrow an exception. Maybe you don't even know that the library code you are calling is going to throw!

A "neverthrows" block would not compile if there is anything inside that can throw (even a runtime exception). Its a way of drawing a line. A library author could use it to make sure no unexpected exceptions can bubble up.

And yeah, if you get NPEs at random you are making a mistake. If I could just choose to not make mistakes, I would :-D. But until then, I'd prefer the compiler to check my work. (And catching them is not an option. What do you do then? Terminate the program? Ignore them? They need to be found at compile time, not at runtime.)

This is a really hard problem. If you use exceptions at any level they have to be generated consistently, or the solution will be what we have now.

Because that's the other thing--you can't guarantee InterruptedException will even be delivered to a thread. An underlying library can just eat it or the thread could be waiting on a socket [1], etc. This kind of behavior the bane of correctness or even getting operations like clean server shutdown to work at all in some cases.

So I think this really needs to be something like CSP that's built into the language in a way that makes the behavior consistent in all cases even if it introduces coding patterns that have other costs. Java _did_ get object locking and data visibility right by building in simple primitives like the synchronized keyword into the language. You can create deadlocks but the behavior is clean enough it's not hard to program around them.

I would also be fine with just dying as long as there is a way to clean up shared data structures. However, that can't be manual because it's just about impossible to ensure that such cleanups are correct. Databases use transactions to get around that problem.

[1] https://stackoverflow.com/questions/1024482/stop-interrupt-t...

Aaaagh! I forgot about that one. This is like Lucy pulling away the football from Charlie Brown.

It's inconvenient because null could be considered a case

  switch(s) {
    case null: return false;
    case "y": return true;
    default: return false;
  }

The broader issue is that Java handles null inconveniently.

1) Every object can be null, switch requires the argument to be non-null, and the type system doesn't warn you when NPE are possible. A type system which handles nullability could fail to compile if 's' is nullable. Kotlin does this, and it let's you opt-in to the NPE with some convenient syntax:

  switch(s!!)

2) It's inconvenient to handle null as a value. To properly handle the null case without throwing, you need to do one the following:

  if(s == null) { ... }
  else switch(s) { ... }

  switch(s == null ? "some-default" : s)

The first way can be made more convenient if you change switch to work on nullable values. The second way is inconvenient, so people generally skip it. If you want switch to only work on non-null values, there're more convenient syntaxes to handle null, such as the 'elvis operator':

  switch(s ?: "some-default")

I assume this is because null is false-y in many other languages, and can be used in switch/if statements and so on. Rather than having to be treated like an error.

Some things that came to my mind:

- List<T> doesn't "just work" with non-reference types. It needs boxing that increases memory usage and introduces stuff like ints being null.

- We need special functional interfaces for non-reference types for that reason (e.g. IntConsumer).

- This also affects Stream<T>, so we need IntStream etc.

- A method must have a parameter of that generic type (or it has to belong to a class that has this generic type). It otherwise becomes indistinguishable during rumtime. For example, a method like ImmutableList.CreateBuilder<T>() is not possible in Java (that example is from C#'s collection types).

Type erasure moslty comes into play when looking at non-reference types. For reference types, it seems to work pretty good (although it's weird that Map<String, String> will have the same runtime type as Map<Object, Object>). The last point I mentioned is not good, but no deal breaker. If generics would be like in .NET, we wouldn't have any of these restrictions.

With type erasure, we ironically have to write more java code while not being able to express stuff in an abstract manner (Stream<T> is incompatible with IntStream).

Type erasure makes deserialization a pain. This has lead to multiple incompatible implementations of ways to indicate what a generic type contains on top of the existing type system. In practice it means using generic types on DTOs is a pita.

Thank you for replying. It helps me to better articulate my thinking. You're my Rubber Duck.

Why would network programming (I/O, persistence, etc) look any different whether the language was C, Java, GoLang or other?

Most of my code is error checking and handling. (And now logging too, which I'll ignore here.) Is this abnormal? (Being rhetorical.)

Plenty of noob code ignores errors. I sort of thought we all decided that was suboptimal. Java's response was checked exceptions.

The only argument I've ever heard that made any sense is the silliness of catching exceptions so far removed from the root cause that your code can't do anything about it.

So don't do that.

Really, why would any one design a system that way? Because network programming is messy? Because it'd be neat to compartmentalize the messiness?

I've been able to cleanly separate the value add business logic from real world messiness exactly one time. I was in control of the full stack, end to end. Imagine something like a useful BizTalk. I had been inspired by postfix. My engine would pass work to plugins, which didn't have to do any I/O of their own. My work anticipated serverless and AWS Lambda, if those programming frameworks (paradigms) were better designed.

It now occurs to me that the checked exception abolitionists are advocating Happy Path Programming.

The only other feasible Happy Path Programming strategy I know of is Erlang. I've only done an Erlang tutorial, nothing in prod, so this is just a guess.

My bias there is that I'm one of those Alan Kay worshipping hard-liners who thinks there's a lot more to object-oriented programming than simply using objects. Similar to how there's more to functional programming than using first-class procedures.

So yeah, it's true, Java has classes. But its culture and idioms and standard libraries and even some language features (checked exceptions, for example) are forever pushing developers toward procedural idioms. Less so now, perhaps, but intensely so in the 1990s.

I can't write a method like this:

public <T> higherOrderFunction(Function<T> f) throws whatever f throws { }

I can write a method that takes in a function object that throws zero checked exceptions. I can write a method that takes in a function that throws exactly one type of checked exception. I can write a method that takes in a function object that can throw two types of checked exceptions. And so on. But this involves lots of copy-pasting, which is the opposite of abstracting.

Checked exceptions are not first-class citizens in the language (see https://en.wikipedia.org/wiki/First-class_citizen). Unlike return values, I can't, for instance, in the general case assign the possible checked exception thrown by a method to a variable without losing type information. To do so would require sum types, a feature which most popular languages don't have.

On the other hand, if I create a class like IO<T>, which represents a possible return value of T or an IOException, then that is first class in the language and I can do anything with it that I can do with any other first-class value in the language.

Well, that I did not know. But I'll take it as the exception that proves the rule if only one language copied it.