Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Exception Patterns (2013)

wiki.c2.com

Post reply on HN
Print view View original

11–20 of 30 posts

Re: Exception Patterns (2013)

#11

Post by epolanski »

The biggest "issue" with exceptions is that they are not exceptions at all.

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

Re: Exception Patterns (2013)

#13

Post by monkpit »

epolanski wrote: post #11

The biggest "issue" with exceptions is that they are not exceptions at all. 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,…

Is there any post you know of documenting this in more detail? I’d be interested to read more.

Re: Exception Patterns (2013)

#14

Post by layer8 »

marginalia_nu wrote: post #5

As a random tangent, this is an "exception pattern" (Java). int foo() { int i; for (i = 0; i Compiles. Runs. Returns 5.

This is not an “exception pattern”. It’s just how the language works, and is a consequence of the concept of “abrupt completion”. It means that you can unconditionally (i.e. independent from whether there is an exception or not) divert the control flow using finally. It’s not much different from how when an exception is thrown from the finally block, the prior exception gets lost.

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

Re: Exception Patterns (2013)

#15

Post by donatj »

gwbas1c wrote: post #2

I don't get the navigation pattern on the page. When I click on a link it opens a panel that I can't close, but then if I push refresh I'm taken to a page with a broken back button. 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…

It really is a shame all this interesting information is stuck in this bizarre unusable site.

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.

Re: Exception Patterns (2013)

#16

Post by marginalia_nu »

layer8 wrote: post #14
marginalia_nu wrote: post #5

As a random tangent, this is an "exception pattern" (Java). int foo() { int i; for (i = 0; i Compiles. Runs. Returns 5.

This is not an “exception pattern”. It’s just how the language works, and is a consequence of the concept of “abrupt completion”. It means that you can unconditionally (i.e. independent from whether there is an exception or not) divert the control flow using finally . It’s not much different from how when an exception is thrown from the finally block, the prior exception gets lost. From the language spec [0]: If the…

It is a pattern with an exception.

Re: Exception Patterns (2013)

#17

Post by enobrev »

codetrotter wrote: post #8
gwbas1c wrote: post #2

I don't get the navigation pattern on the page. When I click on a link it opens a panel that I can't close, but then if I push refresh I'm taken to a page with a broken back button. 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…

> When I click on a link it opens a panel that I can't close, but then if I push refresh I'm taken to a page with a broken back button. 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?

Unfortunately not. I thought this thread was being overly-picky until I opened the link. This is awful.

Re: Exception Patterns (2013)

#18

Post by layer8 »

marginalia_nu wrote: post #16
layer8 wrote: post #14

Earlier quoted context omitted.

This is not an “exception pattern”. It’s just how the language works, and is a consequence of the concept of “abrupt completion”. It means that you can unconditionally (i.e. independent from whether there is an exception or not) divert the control flow using finally . It’s not much different from how when an exception is thrown from the finally block, the prior exception gets lost. From the language spec [0]: If the…

It is a pattern with an exception.

Patterns are solutions or practices applicable to a certain problem. The code you presented isn't that.

Re: Exception Patterns (2013)

#19

Post by valenterry »

epolanski wrote: post #11

The biggest "issue" with exceptions is that they are not exceptions at all. 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,…

Unfortunately, even with fp-ts, typescript does not yet have the means to enable ergonomic handling of errors without exceptions. I hope they improve this in the future though.

Re: Exception Patterns (2013)

#20

Post by epolanski »

valenterry wrote: post #19
epolanski wrote: post #11

The biggest "issue" with exceptions is that they are not exceptions at all. 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,…

Unfortunately, even with fp-ts, typescript does not yet have the means to enable ergonomic handling of errors without exceptions. I hope they improve this in the future though.

As a daily fp-ts user I'm not sure I agree, you handle them with the appropriate data type: Either.

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

Post reply on HN