Exception Patterns (2013)
wiki.c2.com
wiki.c2.com
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.
It actually used to be normal HTML... the site is the first wiki. For some reason it was reimplemented as a broken JS app.
https://www.wired.com/2012/07/wiki-inventor/
But his implementation of it for some reason involved rewriting it as an SPA, which he entirely botched.
Adding my opinion, also let the text use the page width. Limiting it to 120 characters or whatever is fine, but what this site does is really not.
On mobile I just tap outside of the panel to close it. Probably on desktop it will close as well if you click outside of it?
Update - took me a solid 3 minutes of futzing with it to figure out you can close something by clicking on it's parent. Clicking on the grey area does not work.
int foo() {
int i;
for (i = 0; i < 10; i++) {
try {
throw new RuntimeException();
}
finally {
if (i < 5) {
continue;
}
else {
break;
}
}
}
return i;
}
From the language spec [0]:
If the finally block completes abruptly for reason S, then the try statement completes abruptly for reason S (and the throw of value V is discarded and forgotten).
[0] https://docs.oracle.com/javase/specs/jls/se8/html/jls-14.htm...
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.
Exceptions are a path like any other, there's nothing really magical about those, you catch the functions that could throw and handle the fact they have thrown the error, which error, why?
There's two helpers for that in fp-ts [1][2] plus the obvious lazy and asynchronous counter parts in the TaskEither and ReaderTaskEither modules.
[1]https://gcanti.github.io/fp-ts/modules/Either.ts.html#trycat...
[2]https://gcanti.github.io/fp-ts/modules/Either.ts.html#trycat...
That being said, I think the authors did a great job to make it as good as possible given the limitations.
I know fp-ts very well and it does not have those limitations you're speaking of.
Either admits all of the functor, bifunctor, monad, apply, applicative and traversable instances in fp-ts (so do all the other bifunctors) so there's no shortage of combinators.
https://codesandbox.io/s/wispy-shadow-7789p6?file=/src/index...
In whatever ways you want to complicate it (with exceptions, asynchronous operations, with or without Do syntax) you can easily do that in fp-ts.
That's actually not too bad!
do {
result1 <- either1
result2 <- either2
result3 <- fooReturningEither(result1, resul2)
} yield result1 + result3
> 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.