惯性聚合 高效追踪和阅读你感兴趣的博客、新闻、科技资讯
阅读原文 在惯性聚合中打开

推荐订阅源

F
Full Disclosure
WordPress大学
WordPress大学
小众软件
小众软件
Cloudbric
Cloudbric
AWS News Blog
AWS News Blog
腾讯CDC
量子位
人人都是产品经理
人人都是产品经理
大猫的无限游戏
大猫的无限游戏
freeCodeCamp Programming Tutorials: Python, JavaScript, Git & More
V
Vulnerabilities – Threatpost
Scott Helme
Scott Helme
Hugging Face - Blog
Hugging Face - Blog
博客园_首页
C
CXSECURITY Database RSS Feed - CXSecurity.com
The Hacker News
The Hacker News
奇客Solidot–传递最新科技情报
奇客Solidot–传递最新科技情报
IT之家
IT之家
Jina AI
Jina AI
Attack and Defense Labs
Attack and Defense Labs
S
SegmentFault 最新的问题
Simon Willison's Weblog
Simon Willison's Weblog
The Cloudflare Blog
阮一峰的网络日志
阮一峰的网络日志
T
Tailwind CSS Blog
Last Week in AI
Last Week in AI
博客园 - 【当耐特】
Google Online Security Blog
Google Online Security Blog
美团技术团队
OSCHINA 社区最新新闻
OSCHINA 社区最新新闻
V
Visual Studio Blog
罗磊的独立博客
L
LINUX DO - 最新话题
博客园 - Franky
博客园 - 叶小钗
Apple Machine Learning Research
Apple Machine Learning Research
The Last Watchdog
The Last Watchdog
J
Java Code Geeks
AI
AI
C
Cisco Blogs
酷 壳 – CoolShell
酷 壳 – CoolShell
C
Cyber Attacks, Cyber Crime and Cyber Security
Cisco Talos Blog
Cisco Talos Blog
博客园 - 三生石上(FineUI控件)
雷峰网
雷峰网
Help Net Security
Help Net Security
钛媒体:引领未来商业与生活新知
钛媒体:引领未来商业与生活新知
云风的 BLOG
云风的 BLOG
I
Intezer
S
Securelist

Anže's Blog

The 15-Year-Old iptables Rule That Broke My DNS Fedidevs 9h Outage Postmortem Letting Claude Upgrade My Raspberry Pi Agents Day Lisbon DjangoCon Europe 2026 How to Safely Update Your Dependencies Speeding Up Django Startup Times with Lazy Imports Typing Your Django Project in 2026 Claude Fixes User Bug Jekyll to Hugo Migration Advent of Code 2025 🎄 Django bulk_update Memory Issue Migrating Gunicorn to Granian Disable Network Requests When Running Pytest Disable Runserver Warning in Django 5.2 Autogenerating og:images with Jekyll Power Outages and Gunicorn PID Files UV with Django Packages Do Not Match the Hashes Pip Error Gotchas with SQLite in Production Fedidevs Dev Update #2 Django SQLite Production Config Django Streaming HTTP Responses Deploying a Django Project to My Raspberry Pi (Video) Thoughts on Code Reviews Django SQLite Benchmark Django, SQLite, and the Database Is Locked Error No Downtime Deployments with Gunicorn SQLite Write-Ahead Logging Writing a Pytest Plugin Fedidevs Dev Update #1 Django-TUI: A Text User Interface for Django Commands Automate Hatch Publish with GitHub Actions Words TUI: App for Daily Writing Textual App Auto Reload RDS Blue/Green Deployments Fly.io Certificate Renewal Using Testing Library with Selenium in Python The Fastest Way to Build a Read-only JSON API import __hello__ Enum with `str` or `int` Mixin Breaking Change in Python 3.11 Your Code Doesn't Have to Be Perfect Fixing _SixMetaPathImporter.find_spec() Not Found Warnings in Python 3.10 Upgrading Django App to Python 3.10 Integer Overflow Error in a Python Application Python Dependency Management MySQL Performance Degradation in Django 3.1 New Features in Python 3.8 and 3.9 The Code Review Batch Size The Code Review Bottleneck
Go-like Error Handling Makes No Sense in JavaScript or Python
Anže Pečar · 2024-08-16 · via Anže's Blog

Yesterday, I saw this proposal to add Golike error handling to Javascript, which got me thinking about whether or not this would make sense in my go-to language, Python.

TLDR: Even though I am a fan of Go’s error handling, I don’t think the safe assignment operator adds any value to Python or Javascript. For the real solution, we’d probably have to look at Java instead 😅

Some background

I’ve spent the last few months writing Go code, and even though I found error handling in Go very odd at first, I’ve grown to like it more than I expected. I am now at a point where I kind of miss it when writing Python.

Go doesn’t have a try/catch concept that we know in most other languages. Instead, any function that can raise returns an error as one of the return values. Error handling is then done with an if statement like this:

resp, err := http.Get("http://example.com/")
if err != nil {
  // Handle error
}

You’ll see if clauses like this all over the codebase at almost every function call. It seems lengthy at first, but after a while, you get it and start appreciating it.

The big win with this approach is that it forces every function to document its errors. You can’t write a function that can raise an error without having the error in the function signature.

Go’s error handling is great not because you use an if statement, but because you are forced to write one every time you might have an unexpected error.

Unwrap’s popularity in Rust shows that handing errors with if/match statements will often be avoided if there is a better option (pun intended).

Error handling in Python

In Python, a similar HTTP request is usually written as:

response = requests.get("http://example.com/")

Nothing in this line of code tells you that something can go wrong with the get function call. The function signature doesn’t tell you that get can raise a ConnectionError, and neither does the documentation! The only way to know that exceptions can be raised is to read the source code for get or remember it from past experience!

This is what bothers me about error handling in Python. We sweep errors under the rug and assume that everything will be okay. The machine will always have network access, right?

That’s not always the case, and when it’s not, you’ll be woken up in the middle of the night with your production server on fire.

Even if you know that requests.get can raise a ConnectionError,, you will often forget to write the code to handle it because it’s not in your face the same way as Go’s error is.

The Safe Assignment Operator

The idea behind the safe assignment operator is to be able to transform this code:

try:
  response = requests.get("http://example.com/")
except Exception err:
  # Handle error

Into:

response, error ?= requests.get("http://example.com/")
if error:
  # Handle error

It’s syntactic sugar that removes one line of code and one indent. The real problem - knowing that the function can raise an exception - is not addressed.

If you don’t know that requests.get can raise, you won’t use the safe assignment operator the same way as you won’t use a try/except.

The real solution

If we really want to reduce the risk of overlooking error handling, the language we have to look at is not Go; it’s (unfortunately) Java!

Java has a way to express raised exceptions in the function signature, by listing the possible raised exceptions with the throws keyword:

class ThrowsExecp {
    static void fun() throws IllegalAccessException
    {
        System.out.println("Inside fun(). ");
        throw new IllegalAccessException("demo");
    }
}

So, not only does Java force you to catch and handle exceptions that each function can raise, but it also explicitly lists all the exception types that can be raised from within the function. This is one step above what Go does!

But, do we really need/want this in Python/Javascript? In some places, yes, but not everywhere! The beauty of Python is that you can write a one-off script in two minutes and never have to care about any types/errors or anything else! But then you can also write a Django monolith with millions of lines of code that has to work correctly all the time!

Therefore, the real solution should be to add some form of optional exception checking to tools like mypy and TypeScript.

BONUS: Does every error even need to be handled?

Even in Go, you often can’t deal with a particular error at the place where the function is called. Because of this, most exception handling in Go wraps the original error and then passes it up the stack:

resp, err := http.Get("http://example.com/")
if err != nil {
  return nil, errors.Wrap(err, "error getting example.com")
}

This is the same thing that we do in Python/Javascript when we don’t handle the exception at all:

response = requests.get("http://example.com/)

Yes, we didn’t add the custom message error getting example.com to the exception as in the Go version, but that’s not really handling the error. We often don’t need a custom message like this in Python/Javascript because the stack traces are richer and usually even include globals and locals. You don’t need any additional information to successfully debug the problem.

So maybe we don’t even need rigorous error checking when stack traces are the default Go, you can also improve the DX around this!.

Verdict

It pains me to say this, but the Java solution would be a better fit for Python/TypeScript, than the proposal of the type safe assignment operator. Either that or we rewrite all existing code to use the equivalent of Rust’s Result.