err != nil Is GOOD? (And Why)

Summary

The speaker discusses the common misconceptions around error handling in programming languages, specifically comparing JavaScript and Go. They argue that while Go requires explicit error handling, which may seem tedious, it leads to more reliable code. JavaScript, on the other hand, often hides errors, resulting in potential unhandled exceptions and lower reliability. The speaker emphasizes the importance of recognizing language weaknesses and considering error handling as a crucial part of programming, rather than dismissing it as annoying.

Takeaways

• 😕 The speaker is addressing a common frustration with error handling in JavaScript, particularly when comparing it to Go's approach.
• 🔍 They introduce a hypothetical JavaScript scenario with async functions 'Foo' and 'Bar' to illustrate the point.
• 🤔 The speaker suggests that while Go's error handling might seem cumbersome, it encourages developers to think about potential errors upfront.
• 👎 The script points out that JavaScript's error handling can be more frustrating due to its implicit nature, often leading to overlooked errors.
• 📝 The transcript discusses the technical differences in how Go and JavaScript handle errors, with JavaScript requiring additional checks for null or undefined values.
• 🛠️ The speaker emphasizes the importance of proper error handling in JavaScript to avoid runtime issues like unhandled promise rejections.
• 🤖 The comparison between Go and JavaScript is used to highlight that error handling, while annoying, is crucial for reliable code.
• 😌 The speaker disagrees with the common sentiment that Go's error handling is bad, arguing that it's just more explicit about potential issues.
• 📈 They mention that JavaScript services often have lower reliability due to insufficient error handling practices.
• 🌐 The script touches on the broader topic of programming language design and how it influences developer habits and code reliability.
• 📚 The speaker concludes by encouraging developers to recognize the weaknesses of the languages they use and to program with awareness of those limitations.

Q & A

What is the main topic of the video script?

The main topic of the video script is the comparison of error handling in JavaScript and Go, with a focus on the challenges and perceptions of error handling in these languages.

What does the speaker suggest about error handling in Go?

The speaker suggests that Go's error handling is often criticized as being verbose and annoying, but it forces developers to think about potential errors upfront, which can lead to more reliable code.

What is the speaker's view on JavaScript error handling?

The speaker believes that JavaScript error handling is often overlooked or 'hidden', leading to less reliable services and more difficulty in correctly programming, especially when handling all error conditions.

What is the issue with JavaScript's 'await' keyword as discussed in the script?

The issue with JavaScript's 'await' keyword is that it can throw an error at any point, and developers may not always handle these errors, leading to potential runtime issues.

Why does the speaker find the process of error handling in JavaScript tedious?

The speaker finds JavaScript error handling tedious because it often requires additional code for error checks and handling, which can complicate the flow of the code and the function signatures.

What is the speaker's opinion on Rust's error handling?

The speaker appreciates Rust's error handling, mentioning that its use of the Result object and the monadic approach to results allows for more flexibility and better error management.

What is the 'process.unhandledRejection' mentioned in the script?

'process.unhandledRejection' is an event in Node.js that is emitted when a Promise is rejected and no error handler is attached to it, indicating an unhandled error scenario.

What does the speaker mean by 'raw dog Jon parse'?

The phrase 'raw dog Jon parse' is a colloquial and humorous way of saying that many developers parse JSON without handling potential errors, which is not a good practice.

What is the speaker's advice regarding comparing error handling across different programming languages?

The speaker advises not to quickly dismiss another language's error handling as bad just because it looks worse at first glance. Instead, understand the differences and recognize the weaknesses in each approach.

Why does the speaker still write TypeScript despite the issues discussed?

The speaker acknowledges the weaknesses of TypeScript but continues to use it because they recognize its benefits and are aware of its limitations, allowing them to program effectively.

What is the speaker's final message about error handling in programming?

The speaker's final message is that error handling is an essential part of programming that should not be ignored or considered annoying. It is better to handle errors upfront to ensure more reliable and robust code.

Outlines

00:00

🔍 Addressing Error Handling in JavaScript vs. Go

The speaker discusses common frustrations with error handling in Go, specifically the annoyance around checking if errors are nil. Using a JavaScript test file for comparison, they highlight how error handling differs between Go and JavaScript. In Go, every function call must explicitly handle errors, which is seen as tedious but necessary for robust code. JavaScript's async/await error handling is compared, noting that it often leads to unpredictable behavior and additional error states. The speaker argues that while Go's approach seems cumbersome, it ultimately results in more reliable code because it forces developers to handle errors explicitly.

05:01

🔄 The Challenges of JavaScript Error Handling

The speaker continues to explore the difficulties of error handling in JavaScript. They highlight how JavaScript often hides errors, leading to unhandled rejections that need to be caught at a higher level, which complicates the error recovery process. The speaker praises Rust's approach to error handling with its Result object and monadic patterns, suggesting it offers a better balance. However, they conclude that despite Go's error handling being annoying, it is more reliable than JavaScript's. They emphasize the importance of recognizing the weaknesses of each language, advocating for informed choices rather than dismissive judgments.

Keywords

💡Error Handling

Error handling is the process of responding to the occurrence of an error within a program. In the video, the speaker discusses the complexities of error handling in JavaScript compared to Go, emphasizing that Go forces developers to consider errors at the time of writing code, which can lead to more reliable software. The speaker uses the phrase 'go error handling' to illustrate the proactive approach Go takes, contrasting it with JavaScript's more reactive and often overlooked error management.

💡Async Functions

Async functions are a type of function in JavaScript that allow asynchronous operations to be written in a synchronous manner. The video script mentions async functions like 'Foo' and 'Bar', which are used to demonstrate the process of handling asynchronous operations and the potential for errors when using 'await' within these functions.

💡Await

The 'await' keyword is used in conjunction with async functions to pause the execution of the function until a Promise is resolved or rejected. In the script, the speaker discusses the use of 'await' in front of function calls like 'Foo' and 'Bar', and how it can lead to errors if not properly handled.

💡TypeScript

TypeScript is a superset of JavaScript that adds static types to the language. The speaker mentions TypeScript, indicating that despite recognizing its weaknesses, they still write TypeScript code. TypeScript is relevant in the context of the video as it provides a way to add type safety and potentially reduce runtime errors in JavaScript code.

💡Go

Go, often referred to as Golang, is a statically typed, compiled programming language designed at Google. The video contrasts Go's error handling with JavaScript's, suggesting that Go's approach is more explicit and upfront about potential errors, which can lead to more robust and reliable code.

💡JavaScript

JavaScript is a high-level, interpreted programming language commonly used for client-side web development. The script discusses JavaScript's error handling mechanisms, or lack thereof, and how they can lead to less reliable code compared to languages like Go.

💡Promises

Promises in JavaScript are objects that represent the eventual completion or failure of an asynchronous operation. The speaker mentions that the return value of async functions can be a promise, which adds complexity to error handling and the function's signature, as seen in the script's discussion about handling 'null' or error cases.

💡Try-Catch

Try-catch blocks are used in JavaScript to handle exceptions. The video script mentions the need for try-catch blocks when calling async functions to handle potential errors that might be thrown, illustrating the reactive nature of JavaScript's error handling.

💡Reliability

Reliability in software development refers to the ability of a system to perform its required functions under stated conditions for a specified period of time. The speaker argues that Go's approach to error handling contributes to higher reliability compared to JavaScript, where errors are often overlooked or handled inadequately.

💡Rust

Rust is a systems programming language that focuses on performance, safety, and concurrency. The script briefly mentions Rust as an example of a language that handles errors in a way the speaker finds more appealing than JavaScript, specifically referencing Rust's 'Result' object for error handling.

💡JSON Parse

JSON parse is a JavaScript function used to convert a JSON string into a JavaScript object. The speaker uses JSON parsing as an example of a common operation in JavaScript that requires error handling, as it can throw an error if the JSON is invalid, highlighting the need for proactive error management.

Highlights

The speaker introduces a comparison between error handling in Go and JavaScript, specifically addressing the common misconceptions about Go's error handling being cumbersome.

A test file named 'test.js' is used to demonstrate the differences in handling asynchronous functions in JavaScript compared to Go.

The concept of 'await' in JavaScript is discussed, highlighting the uncertainty of error handling when using 'await'.

The speaker suggests that writing Go in a JavaScript file is not practical, but uses it as a starting point for the discussion.

The equivalence of error handling between Go and JavaScript is explored, emphasizing the need for special error handling in both languages.

The issue of variable definitions and types in JavaScript is discussed, especially when dealing with null or undefined values.

The speaker criticizes the complexity of error handling in JavaScript, particularly when dealing with promises and null values.

A comparison is made between the error handling in Go and JavaScript, with the assertion that JavaScript tends to have lower reliability due to poor error handling practices.

The speaker argues that Go's error handling, despite being seen as verbose, forces developers to think about errors proactively.

The concept of 'process.unhandled rejection' in JavaScript is mentioned, illustrating the potential for top-level errors that are difficult to manage.

The speaker shares personal thoughts on the tediousness of error handling in JavaScript and the importance of recognizing its weaknesses.

The transcript touches on the use of TypeScript and the speaker's recognition of its limitations.

The speaker emphasizes the importance of not being ignorant about the weaknesses of programming languages and to understand the trade-offs.

A critique of the common complaint about 'if err equals nil' in Go, suggesting that the speaker does not find it as bad as others might.

The transcript concludes with the speaker's belief that contributing to Go is easier and more reliable due to its upfront error handling requirements.

The speaker reflects on the frequency of errors in code, suggesting that JavaScript's error handling often makes them less noticeable.

The final thoughts include a comparison between the error handling in Go and JavaScript, with a preference for Go's approach due to its explicitness.

Transcripts

we're going to do something different

here okay I know this is going to be a

little bit different but I wanted to

talk about a small difference that I see

all the time because I see a lot of

people always getting super hot and

bothered about go air handling if air

equals nil and I want to just take a

little moment and address it just for a

second okay so I'm just going to have

this test file and we're going to call

it test.js okay and let's say I have an

async function you know Foo right and

then I have another one uh bar okay and

I wanted to do something here with that

so I have async function main this and I

could go await Foo and I could go await

bar now in goand what would this look

like this would look something like this

uh right Main and it would look

something like this where I'd actually

have this right and it would look

something you know right can we agree

this is effectively what it would look

like

yeah yeah it would look something like

this right and that's kind of annoying

can we all agree that we don't like that

we we like this typically what people

always say about go is this

sucks this is awesome but there's kind

of a lie that you're being told right

here okay first off you have some

options here right you have some real

options here obviously writing go in a

Javascript file doesn't you know it

doesn't count but just deal with it okay

you could do something like

this

but which one errored remember anytime

there's an await an error can be thrown

you don't know you just simply don't

know so that means if you wanted to

create the equivalent behavior from go

to Java Script what you would have to do

is something like

this this would be the equivalent it

gets even worse though because if you

had a value come out of Fu and bar right

if you had value air uh uh Fu Val uh

right here oh no no wait go does not go

does not do that if you had these two

things right here right BAR value and Fu

air right and then I could do something

like this return uh oh gosh I have these

things backwards just deal with it just

deal with it let's just say we had

something like this to make the same

thing happen in this you would actually

have to do it a bit different right if

you had to do some sort of special error

handling right uh some special error

handling right whatever that special air

handling is it doesn't really matter

what it is we'd have to do the same

special air handling same special air

handling I don't know return uh return

null right we'd have to return null in

both these situations not only that we'd

have to have let Fu Val be right here

which means that we're going to have to

have some sort of type number or null

right because now you have to have like

null or you'd have to do undefined right

you'd have to do some sort of definition

going on here Fu Val equals this you'd

have to Define it on the outside and

then make it go on the inside you're

going to have to do the exact same thing

right here right it's like that's kind

of annoying right that's kind of

annoying I don't want to have to do that

equals this and then you can return Fu

plus bar Val but here's the worst part

is now what does your return statement

look like well your return statement is

promise or

null right it like changes the signature

these errors not only have huge change

in how your flow of code works it also

has a huge change in what your signature

is going to

due to like the return value so now your

outside when calling it also has to

perform the exact same thing it not only

has to do a try catch for potential

errors thrown just in case there's an

error thrown because they don't know if

you handle every error and maybe you

don't handle every single error but on

top of it they also have to handle like

this null case that you might have to

handle right so now it went from a

two-state problem to a three-state

problem and down here in the goand it's

not cuz what would what would the

function look like the function well

based on whatever this is its return

value looks something like error number

right or int

right and so it's going to have the same

it it has the exact same like experience

no matter what and so you go into the

situation without all that it's like I'm

just saying when people say go air

handling is bad you got to understand

the

difference what are you comparing it to

there's a reason why JavaScript Services

tend to have extremely low

n reliability right they're not coming

in with 59 they're just not because you

have to have an intense amount of air

handling everywhere and nobody does that

nobody does that every time you Json

every time you Json parse you need to

handle a potential error so many people

just raw dog Jon pars I'm just saying

when people say go air handling sucks I

simply disagree I say it just forces you

to think about errors when errors can

happen JavaScript they just hide the

errors error is not going to happen you

don't worry you know the worst part

about this whole thing is that at some

point you have something like this

process. un unhandled rejection right

you get some sort of top level error

Catcher And you have to recover from

that you have to reset some State

somewhere

what I mean good luck that's difficult

anyways these are just some thoughts I

have about air handling in this because

I hear this all the time like do I like

doing this I don't like doing this I

think it's tedious and I think it's

annoying I think rust does a much better

job with the result object I think the

monatic approach of results and being

able to morph them an and then being

able to do a okay filter map and all the

different combinations you can do is

absolutely fantastic but at the end of

the day this annoyingness right here is

just significantly better than whatever

this annoyingness looks like it is very

very very difficult

to

correctly program JavaScript so that you

handle all err conditions anyways there

you go just my thoughts JS errors are

very difficult it's very tedious the

problem is I just don't want you to fall

into this habit of thinking that some

other language is bad because it

immediately looks worse on the outside I

will tell you by that at the end of the

day you will find contributing to go

easier and more reliable because it lets

you know ahead of time ah I got some

errors I need to handle I'll take care

of these errors

annoying but man wow there's a lot of

Errors I didn't realize how often code

that I write can error this seems kind

of wild I don't remember my code ever

ering that much with JavaScript oh it

does it's no different it's identical

you just don't know you're dead like

that's the only difference all right the

name is I still write typescript all the

time I'm not saying don't write it I I'm

just saying I I don't love it I

recognize its weaknesses okay and you

should recognize the weaknesses too and

then you can continue to program it but

I don't want you to be someone that's

just simply ignorant or say stupid

things like if air equals nil is just

the worst is it the worst is it the

worst I don't know I don't

know I don't know a jet