• My understanding of error handling

    Based on the Algebraic-data type, we can define a type that represents either success with a value or failure with a reason. It's often called Result. In Rust, this is a standard way to handle the error. In Kotlin and TypeScript, the languages provide an exception mechanism as the common way to handle the error, and there are third-party libraries that provide the Result type. In this article, I explain my understanding of error in programming and my ideal way to handle error.

  • My understanding of OOP and FP

    | /

    In my previous article, I explain my understanding of programming languages in general. In this article, I will explain how I view Object-oriented programming (OOP) and Functional Programming (FP).

    TL;DR: OOP is good for expressing general objects, while FP focuses on some specific cases. Kotlin and Scala match my understanding closely. Other languages like Rust and even TypeScript are also good if they can express the same idea that OOP and FP can.

  • Not Pattern - an Algebraic Data Types alternative invented by me

    | /

    Chinese Version

    TL;DR: Summary

    Algebraic Data Type (abbreviated ADT, sometimes called Discriminated Union, Tagged Union, enum in Rust) is a language feature which can be used to express that a data has multiple cases and each case has different content. Compared with inheritance or interface implementation, sometimes the cases and structure of a data are stable, but the operation of this data (especially the operation of different processing according to the case) is uncertain and extensible. Algebraic data types are suitable for this situation. Currently, many languages do not support this language feature. This article will introduce a pattern of my own design to express this kind of data, finding a balance between ease of use and less error-prone.

  • Simulate exception in async Rust

    | /

    WARNING: This may be a bad practice. The point of this article is just to share my idea.

    Exception is a popular feature in many programming languages. Unlike Rust where errors are considered as a return value of the Err case of Result, in these languages errors are thrown like panic. The caller may catch the errors and process them similar to catch_unwind in Rust. Different people may have different preferences on the error handling style, but panic-unwind is always considered a bad practice and should be avoided if possible. So using exception-like error handling in Rust is impossible.

    Well, it is possible with async Rust, but we need a little trick. The main idea here is to stop polling the future after an exception is thrown.

  • Customized trait object in Rust

    | /

    I love the traits in Rust language. Rust uses one mechanism for both compile-time polymorphism and runtime polymorphism, which is elegant. However, the runtime polymorphism in Rust is not very flexible. Some traits cannot be used as a trait object, and it's impossible to specify whether a method is resolved dynamically or statically. This shortage is reflected in my recursive function library RecurFn, and I develop a workaround, calling it customized trait object.