Vafiadis: Which async/await takes away

Paulhus: How is the code i’m calling handling it’s own exceptions?

Elvis: If it calls something that thows an exception

Elvis: I need to know if it handles that

Elvis: Or expects it to be handled higher up

Elvis: Are you saying you shouldn’t let them bubble up? because that’s like, the point of exceptions.

Vafiadis: You have to validate the return either way – it’s just that if you fail to validate on a throw, execution stops. If it doesn’t throw, then your code could keep running with an unexpected state

Paulhus: That is what you are saying – think about it. the calling code gives you an option to handle it – like ignore or retry or do whatever

Paulhus: Showing up is handling it too

Paulhus: The default unhandled behaviour

Elvis: Vafiadis: it might stop, it might not. it depends how far it bubbles up, if you had any events pending, etc.

Elvis: Paulhus: i’m not sure i understand what you mean by that

Vafiadis: Tcsc: oh sure, if you have a wrapped try/catch. I thought you were advocating NO try/catch

Elvis: Well, pending events is more common for me

Vafiadis: Though the bubbling can get annoying

Elvis: E.g. you usually requestAnimationFrame pretty soon after the last one

Vafiadis: Makes it harder to trace the issues

Paulhus: It’s at least wrong to say the code i am calling needs to handle its own exception. it just expects some things that can go wrong and gives you the option to handle it differently depending on what caused the error.

Vafiadis: I’m kinda shocked to see tcsc advocate an FP technique though ;-

Elvis: I mean, i actually like functional programming, i just think it has a necessary overhead in JS that makes it not worth using for what i do

Elvis: Paulhus: it seems to me like you’re advocating not caring a ton about what code gets executed during error cases

Buttery: Thanks Paulick! I got my cache problem solved! :

Elvis: E.g. if you have foo bar baz, if it’s an error case in bar you shouldn’t care about whether or not baz gets executed

Elvis: That sounds dodgy to me.

Fasula: Syntax error, missing ;

Elvis: I would agree probably in the case of a programmer error

Paulhus: You have usually sth like try { } catch thatWentWrongException { you can handle something programmatically here without confronting the user } catch Exception { something unexpected went wrong }

Paulhus: Exceptions are not just debug messages to be displayed to the user

Paulhus: Often they are though

Elvis: I mean, i never said they were

Elvis: I don’t think they are.

Elvis: Fwiw there’s probably a bit of an attitude difference here, generally for the type of code i write, i would say running in an invalid state is better than crashing, except for debug builds

Paulhus: If i stumble over a good example i may let you know

Paulhus: Crashing = unhandling exceptions

Elvis: It can be other things too though.

Paulhus: Like an asteroid destroyed the earth exception

Paulhus: Okay. well. worst case is the os crashes too.

Coney: Just asteroid /dev/null

Elvis: Send the asteroid off to the physics engine and hope for the best.

Elvis: Actually i’ve crashed the OS before. earlier versions of mac os x would kernel panic in some cases if you mishanlded your gl contexts while in full screen

Elvis: Either way, a certain amount of my dislike from exceptions comes from dealing with them in c++, but i still think they’re not so good in general.

Paulhus: Even a bluescreen is exception handling.

Elvis: Different kind of exception

Paulhus: When i was young computers were exploding when not unplugged