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