Audio source: https://www.svelteradio.com/episodes/svelte-language-tools-with-simon-holthausen (55 mins in)
My blogpost: Errors are Not Exceptions
swyx: [00:00:00] A while ago, I started learning Go and found that there was an interesting difference between how Go handles errors and exceptions compared to JavaScript. So I wrote a blog post called errors versus exceptions. And that blogpost really stuck in my mind so much so that in a recent episode of Svelte Radio i pulled it out again as my unpopular opinion so here it is.
All right. Other unpopular opinions. I've got a quick one, I've been learning goal recently for my new job and I realized that. Other languages handle exceptions and errors differently than JavaScript. And I did not know that there was any other way to do this because my only prior exposure was Python and JavaScript and they treat them the same, the exact same way, but in go, or let's say in rust, you don't really throw unless you really like shit is hitting the fan and the error the program needs to end right now.
Whereas in JavaScript is pretty normal to throw. Whatever area you want. And then you would just expect someone you document that someone above should catch you. You expect someone to catch you somewhere. And then the program is going to recover and continue. From an error. And so I I realized this when I, yeah.
I was just like, exploring like, what is, what's the difference between errors and exceptions like that? I don't know if you guys have ever thought about it.
Antony: [00:01:12] I have thought about it because in Java where I originally came from, it's two very different concepts. So it and an error, sorry.
An exception is something quite normal. It's an exception to the flow of the program or the circumstance you're in. And you can even do exception, different programming, which I used to do quite a lot, where you just have. So Java has very good exception catching it. Doesn't have like JavaScript.
We have to inspect what kind of code is or read some texts out of the message. It has explicit types around what you're throwing. So you can make a catch date with multiple catches and just say this type, do this, this type, do this. So an error in Jarvis thing that if you throw an error in Java, your program equates that's the end, right?
And error is critical. It's your system is broken and you always never used them. Yeah. When you're programming regularly, you never really used it. You shouldn't use them, especially web apps, but for an exception, that exception is quite a normal thing. And it literally means the truest term. It's an exception to.
The flow you expect to be happening.
swyx: [00:02:11] Yeah. So that, that was what it took me a long while to actually get there because I've never used Java. And then th the other thing that was confusing was go actually names them the opposite way around. So which ones are errors and then areas are
Antony: [00:02:22] that's complex.
swyx: [00:02:24] So it really, really screwed me up. But anyway the unpopular opinion is you should not use. Throw in JavaScript, unless you can really, really avoid it. You should use, you should return an error or you should return it in some sort of error objects. I see Simon and give me a thumbs up. Yeah, definitely.
That
Antony: [00:02:38] is a hard wiring rework of my brain. If I was to do that, to be honest,
swyx: [00:02:43] this is so normal to throw, but we should not be randomly throwing like that. It's not, it's an abusive thrill.
Simon Holthausen: [00:02:48] There, there are concepts in, for example, a functional programming with this either. So you either return the normal thing or something that exception, so to speak, and then you are forced to handle that all the way up the chain.
But I think that's also why it hasn't gotten so popular because if you have to explicitly handle it every time, which is generally a good thing, I think. Many people are just lazy and say, okay, I'm just going to throw a, try, catch somewhere, very up the chain and just deal with it there instead of having to pass around this either all the way up.
But I think it would make for a much more robust code. More
Antony: [00:03:31] predictable quotas. If you're programming, if yeah. I if you're writing a language, like you said, um, If you make it too different to everything else, that's out there, you split the camp into two types of people as those who will adopt it and change their program habits, which should be few.
There are people who will just ignore it completely because it's so different to what they used to. And then there'll be the fanatics who absolutely just love it. The fact does everything differently. Again, be a small counter centers. Describe the. The Elm language quite well, possibly I've not looked at Allen
swyx: [00:04:00] quite possibly either or maybe yeah.
Monads yeah, and then for me, the final realization was that anytime you throw within the anything async, and the moment you have, you, you call promise and you forget to catch that error just goes out the window. It's never handled that doesn't exist and goes to the top.
I actually got mad at JavaScript. I was like, wow this is the reason we have shitty programs in Java scope because we don't have really good discipline around error handling. Anyway, that's my unpopular opinion. You should, we should stop.
Antony: [00:04:34] All right.