IMO: Just do a normal site where links take you to pages. Don't be creative with the UI. Maybe you could use some bog-standard wiki software?

The content itself looks very valuable, but because the UI is so bonkers, it's just too hard to use or link to.

    int foo() {
        int i;
        
        for (i = 0; i < 10; i++) {
            try {
                throw new RuntimeException();
            }
            finally {
                if (i < 5) {
                    continue;
                }
                else {
                    break;
                }
            }
        }
        
        return i;
    }

One of the authors of Stoplight [1] once said during a talk that actually in an http transaction so many things can be wrong (30 major causes in a simple GET http request alone can derive from parsing) that writing http clients or mock servers is actually about handling errors and exceptions and stopping to think about those as unhappy cases, happy cases are, if anything, exceptions.

He then pushed for a complete rewrite of their tools using fp-ts and treating exceptions and errors as normal (algebraic) data types which brought critical failures and bugs to basically 0.

https://github.com/stoplightio

> This site uses features not available in older browsers.

This site used to be good, just plain html, no javascript, little styling to get in the way... What happened to it?

> Don't use assertions. BairsLaw applies - what will you do if the assertion fails? (Fix the bug, perhaps?) If you don't like the parameters you're given, throw an IllegalArgumentException. If you don't get a correct result, your UnitTest will tell you. There is no room left for assertions.

Disagree. How does the “law” apply? Yes, I would like to fix the bug if the assertion uncovers it… not unlike a validation error.

Assertions are only turned on in Java if `-ea`. Which means that you can fail fast for local development and maybe just log things in production.