err != nil Is GOOD? (And Why)
Summary
TLDRThe 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
🔍 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.
🔄 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.
Mindmap
Keywords
💡Error Handling
💡Async Functions
💡Await
💡TypeScript
💡Go
💡JavaScript
💡Promises
💡Try-Catch
💡Reliability
💡Rust
💡JSON Parse
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
Ver Más Videos Relacionados
5.0 / 5 (0 votes)