Elvis: Actually that’s pretty useful.

Elvis: Although maybe i’d just want to crash.

Elvis: Since it would be caught in testing.

Vafiadis: It can depend, I think

Vafiadis: It can help you keep the try/catch to a minimum

Vafiadis: Which in some situations can improve perf

Elvis: I basically never use try/catch

Elvis: I do use .catch with promises though, but i don’t think that’s even a catch under the hood usually.

Vafiadis: Well, the catch happens regardless

Elvis: Either way, i don’t like exceptions because i think they make code harder to reason about.

Vafiadis: Right, I prefer burying them too

Vafiadis: Abstracting them away

Vafiadis: Where possible, at least

Stelb: Tcsc: you’re gonna hate ES7 async functions

Garroutte: Should I reload the styles/js scripts in an ajax script that is intended to display data somewhere in the calling-page ?

Elvis: Why? aren’t they just sugar for promise then changes?

Vafiadis: It means you gotta try/cath all the things again

Vafiadis: Though what most people forget is you can do await somePromise.catchhandleError

Elvis: Yuck. well i don’t do much async code

Croutch: Garroutte: do the stylesheets/scripts change?

Elvis: How does that work, since the code is asynchronous?

Elvis: You just have the catch in the async function?

Elvis: Because that might not be quite as bad for reasoning about the code.

Vafiadis: It’ll unwrap the promise that results from the chain

Paulhus: The reject will vbe p***ed down to the calling catch

Vafiadis: So you’d only get a throw out of that if your handleError function also throws

Elvis: No, i mean how does the non .catchhandleError case work

Garroutte: Deltab: d’oh, wil ltry that now anyway

Garroutte: Just wanted to check :p

Garroutte: Deltab: like the date-picker plugin or the table-sorter plugin or whatever

Harring: Garroutte: if they don’t change, why reload them?

Garroutte: Deltab: sure, lemme do a test 😛

Elvis: My issue with exceptions is mainly that if you use exceptions a lot, and you want to know what you’re going to execute in a funciton, you have to know the exception handling behavior of all the functions you call, and all the functions they call, and etc. it requires a lot of tricky non-local reasoning.

Elvis: If the try/catch is localized to the async block, that doesn’t bother me quite as much.

Elvis: Since it’s outside the control flow of everything else

Barries: Code not using exceptions is usually verbose

Gzym: Because you end up checking return values of everything you do.

Elvis: Maybe. it’s more explicit about what it’s doing.

Paulhus: Not really. they escpecially designed to give a clue what went wrong for sombody who does not know the internal of code

Paulhus: Like how libs are meant to be used

Behlmer: Tcsc: You would be right in a perfect world where people do check return values of functions.

Reader: Garroutte: if there’s some setup that needs to be done again, put it in a function and call that

Garroutte: Deltab: set up like what ?

Paulhus: Also that “i’m not sure how to handle this, i p*** it on to next calling instance, maybe it knows” thing

Smale: Garroutte: like attaching date pickers

Elvis: The problem is that again, you need to know whether or not the code you’re calling handles all the exceptions it might cause in order to know whether or not excution of your code will continue

Vafiadis: That’s why it’s nice to use something monad-esque, where the wrapper knows how to handle the situation and you’re just manipulating the wrapper