Forem: Mykhailo Krainik

BLoC (Business Logic Component) in Rust

Mykhailo Krainik — Fri, 03 Oct 2025 20:16:17 +0000

I’ve heard a lot about the BLoC design pattern from the Dart and Flutter world, and I was curious how it might translate to Rust. Particularly in cases where changes in one part of the system need to trigger updates in others, without explicitly calling functions each time

use tokio::sync::{mpsc, broadcast};
use tokio::task;

#[derive(Debug, Clone)]
enum CounterEvent { Inc, Dec, Reset }

#[derive(Debug, Clone, Copy)]
struct CounterState { value: i64 }

struct CounterBloc {
    // Send events into the bloc:
    pub events: mpsc::Sender<CounterEvent>,
    // Subscribe to states from the bloc:
    pub states: broadcast::Receiver<CounterState>,
}

impl CounterBloc {
    fn new() -> Self {
        let (tx_evt, mut rx_evt) = mpsc::channel::<CounterEvent>(64);
        let (tx_state, rx_state) = broadcast::channel::<CounterState>(64);

        // initial state
        let mut state = CounterState { value: 0 };
        // publish initial state (optional)
        let _ = tx_state.send(state);

        // BLoC
        task::spawn({
            let tx_state = tx_state.clone();
            async move {
                while let Some(evt) = rx_evt.recv().await {
                    match evt {
                        CounterEvent::Inc   => state.value += 1,
                        CounterEvent::Dec   => state.value -= 1,
                        CounterEvent::Reset => state.value = 0,
                    }
                    let _ = tx_state.send(state); // broadcast new state
                }
            }
        });

        Self { events: tx_evt, states: rx_state }
    }
}

#[tokio::main]
async fn main() {
    let bloc = CounterBloc::new();

    // Receiver and react to state changes:
    let mut state_rx = bloc.states.resubscribe();
    tokio::spawn(async move {
        while let Ok(s) = state_rx.recv().await {
            println!("State change = {:?}", s);
        }
    });

    // Simulate UI intents:
    let _ = bloc.events.send(CounterEvent::Inc).await;
    let _ = bloc.events.send(CounterEvent::Inc).await;
    let _ = bloc.events.send(CounterEvent::Dec).await;
}

Output:

State change = CounterState { value: 1 }
State change = CounterState { value: 2 }
State change = CounterState { value: 1 }

Also this might be especially useful in UIs built with Dioxus or Tauri, where changes are expected to trigger immediate reactions across the system.

Adapter Design Pattern in Rust

Mykhailo Krainik — Fri, 03 Oct 2025 20:14:30 +0000

The adapter pattern helps two things work together when their interfaces don’t match. It’s a structural design pattern because it connects and combines the features of both.

Let’s say we have a LegacyCourier object and a function that should

fn do_delivery(sender: impl Delivery)

send the data. How do we connect them so that other delivery methods also work? This is where the Adapter Pattern comes in handy. Let’s look at the following code.

use std::sync::Arc;
use std::thread;

// Unified interface used by the app.
trait Delivery: Send + Sync {
    fn deliver(&self, msg: &str);
}

// A modern implementation (already matches the trait).
struct HttpDelivery;

impl Delivery for HttpDelivery {
    fn deliver(&self, msg: &str) {
        println!("[HttpDelivery] POST /deliver => \"{}\"", msg);
    }
}

// ----- Legacy system (incompatible interface) -----
struct LegacyCourier;

impl LegacyCourier {
    // Legacy API ships raw bytes (not &str) and has a different method name.
    fn ship(&self, data: Vec<u8>) {
        println!("[LegacyCourier] shipping {} bytes", data.len());
    }
}

// Adapter: wraps LegacyCourier and exposes the Delivery trait.
struct LegacyCourierAdapter {
    inner: LegacyCourier,
}

impl LegacyCourierAdapter {
    fn new(inner: LegacyCourier) -> Self {
        Self { inner }
    }
}

impl Delivery for LegacyCourierAdapter {
    fn deliver(&self, msg: &str) {
        // Adapt &str -> Vec<u8> for the legacy API.
        self.inner.ship(msg.as_bytes().to_vec());
    }
}

We can now use LegacyCourier in a new delivery method via an adapter, while keeping the old interface intact. This is a very powerful example, as LegacyCourier can still be used in legacy code where changes are undesirable. By implementing a delivery interface for LegacyCourier, we avoid modifying the legacy code, but can extend it as needed without the risk of breaking backward compatibility.

fn main() {
    // Legacy system part
    let courier = LegacyCourier;
    let courier_adapter = LegacyCourierAdapter::new(courier);
    do_delivery(courier_adapter);

    // Modern system part
    let http = HttpDelivery;
    do_delivery(http);
}

fn do_delivery(sender: impl Delivery) {
    sender.deliver("some message");
}

Output

[LegacyCourier] shipping 12 bytes
[HttpDelivery] POST /deliver => "some message"

Using Either/Result in TypeScript for Error Handling

Mykhailo Krainik — Fri, 03 Oct 2025 20:12:15 +0000

In this article, we will take a different perspective on the Either/Result type to explore a better approach to error handling in TypeScript. Find the best and most convenient way to handle error handling for the entire code base.

A consistent error handling approach is about making a choice for error handling and adhering to it consistently throughout your codebase. Common strategies include using exceptions, Result/Either types, or custom error objects.

First of all, let’s focus on the Either/Result type. We will discuss what the Either/Result type is and how we can achieve it in TypeScript. If we look at Haskell, the Either type represents values with two possibilities: a value of type Either a b can be either Left a or Right b. If you’re coming from Rust, Result<T, E> serves as the type for handling and passing along errors. It takes the form of an enum with two variants: Ok(T), signifying a successful result and holding a value, and Err(E), indicating an error condition and containing an error value

When we discuss the Either type in TypeScript, the fp-ts library empowers developers to build pure functional programming apps, using key abstractions from languages like Haskell, PureScript, and Scala.

type Either<E, A> = Left<E> | Right<A>

Now, let’s look at a simple example. When we send a request and process data based on the server’s response.

import * as P from 'fp-ts/lib/pipeable';
import * as E from 'fp-ts/lib/Either';
import axios, { AxiosResponse, AxiosError } from 'axios';

// Custom error type
type ResponseError = string;

async function makeApiCall(): Promise<E.Either<ResponseError, AxiosResponse>> {
  try {
    const response = await axios.get('https://jsonplaceholder.typicode.com/posts/1');
    return E.right(response);
  } catch (error) {
    const axiosError = error as AxiosError;
    return E.left(`API Error: ${axiosError.response?.statusText || 'Unknown'}`);
  }
}

const post = makeApiCall()
  .then((apiResponse) => {
    P.pipe(
      apiResponse,
      E.match(
        (error: ResponseError) => {
            console.error(error);
            return null
        },
        (response: AxiosResponse) => response.data
      )
    );
  });

As we can see, the response of makeApiCall will have a type Either<ResponseError, AxiosResponse>, which protects us from any undefined error behavior. fp-ts is a powerful library, and I prefer using it over Ramda or Lodash/fp. Also EffectTS implementing some fp-ts concepts.

But what about situations where you cannot introduce a new dependency into your project and need to find the best solution for it? I must say, I love the Rust programming language. It introduces the Result type, from which we can extract a minimal subset to create our version of the Either type.

/**
 * Represents a custom type that can hold either a successful result or an error.
 * It is defined as a tuple with two optional elements, T for success and E for error.
 */
export type Result<T, E> = [T | null, E | null];

/**
 * Creates a new `Result` object representing an error condition (`Err`).
 *
 * The function takes an `Error` object and constructs a `Result` tuple
 * with a `null` value for success and the provided error value.
 */
export const Err = <T extends Error>(error: T): Result<null, T> => [null, error];

/**
 * Creates a new `Result` object representing a successful outcome (`Ok`).
 *
 * The function takes a value of type `T` (or `null`) and constructs a `Result` tuple
 * with the provided value for success.
 */
export const Ok = <T>(result: T | null): Result<T, null> => [result, null];

/**
 * Checks if the given `Result` object represents an error (`Err`).
 *
 * The function examines the `Result` tuple and determines if it represents an error case.
 * It returns a boolean value indicating whether the `Result` is an error.
 */
export const isErr = <T, E>(result: Result<T, E>): result is [null, E] =>
  result[0] === null && result[1] !== null;

/**
 * Checks if the given `Result` object represents a successful result (`Ok`).
 *
 * The function examines the `Result` tuple and determines if it represents a successful outcome.
 * It returns a boolean value indicating whether the `Result` is a success.
 */
export const isOk = <T, E>(result: Result<T, E>): result is [T, null] =>
  result[0] !== null && result[1] === null;

/**
 * Matches the result of a `Result` type and applies the appropriate callback function.
 * If the `Result` is `Ok`, the `onSuccess` callback is called with the value of type `T`.
 * If the `Result` is `Err`, the `onError` callback is called with the error value of type `E`.
 */
export const match = <T, E, R>(
  result: Result<T, E>,
  onSuccess: (value: T) => R,
  onError: (error: E) => null | unknown
): R => {
  if (isOk(result)) {
    return onSuccess(result[0]!);
  } else {
    return onError(result[1]!);
  }
};

Now, let’s explore an example, similar to what we previously discussed with fp-ts, but this time, we’ll utilize a custom Result type.

import axios, { AxiosResponse } from 'axios';
import Result, Ok, Err from 'result';

// Create an API request function that returns a Result
async function makeApiCall(): Promise<Result<AxiosResponse, Error>> {
  try {
    const response = await axios.get('https://jsonplaceholder.typicode.com/posts/1');
    return Ok(response);
  } catch (error) {
    return Err(error as Error);
  }
}

// Use the makeApiCall function and match the result
const apiResult = await makeApiCall();
const post = match(
  apiResult,
  (response) => {
    // Handle successful result
    return response.data;
  },
  (error) => {
    return `Error: ${error}`;
  }
);

When we look at the same concept in Rust, it appears quite similar, doesn’t it?

use reqwest;
use std::error::Error;
use std::result::Result;

async fn make_api_call() -> Result<String, Box<dyn Error>> {
    match reqwest::get("https://jsonplaceholder.typicode.com/posts/1").await {
        Ok(response) => match response.text().await {
            Ok(data) => Ok(data),
            Err(err) => Err(Box::new(err)),
        },
        Err(err) => Err(Box::new(err)),
    }
}

#[tokio::main]
async fn main() {
    let post = make_api_call().await;

    dbg!(&post);
}

It’s not identical, but it can be very close to what we’ve discussed.

However, when you consider TypeScript, the package fp-ts brings functional programming features to the table. In any case, you can also create your custom version of Either/Result, just as I did.

Now, let’s go back and look at the common strategies, which include using exceptions, Result/Either types, or custom error objects.

import axios, { AxiosError } from 'axios';
import { Either, left, right, isLeft } from 'fp-ts/lib/Either';

type CustomError = {
  type: 'CustomError';
  message: string;
};

type NetworkError = {
  type: 'NetworkError';
  message: string;
};

type AppError = CustomError | NetworkError;

type Result<T> = Either<AppError, T>;

async function makeApiCall(): Promise<Result<any>> {
  try {
    const response = await axios.get('https://jsonplaceholder.typicode.com/posts/1');
    return right(response.data);
  } catch (error) {
    if (axios.isAxiosError(error)) {
      return left<NetworkError>({ type: 'NetworkError', message: error.message });
    } else {
      return left<CustomError>({ type: 'CustomError', message: 'Something went wrong.' });
    }
  }
}

const apiResult = await makeApiCall();

const output = isLeft(apiResult)
  ? `Error: ${apiResult.left.message}`
  : `Data received: ${apiResult.right}`;

I trust that these insights will enhance your error handling practices. However, it’s essential to pay close attention to the following considerations. Creating error objects at the module level provides more detailed information for code debugging. Combining Either type objects enables you to handle situations where positive or negative results might be overlooked. Additionally, it’s crucial to maintain the correct context for your error messages and make use of standard error library (ReferenceError, TypeError, etc) to enhance the clarity of your code. Also, remember to consider the varying levels of error logging based on usage, such as using plain text for development and a structured JSON format for production.

⚖️ © Licensed under Creative Commons Attribution 4.0 International (CC BY 4.0).

How can prime numbers be efficiently determined? Economy 100 ms for 100 numbers.

Mykhailo Krainik — Fri, 03 Oct 2025 20:06:04 +0000

How to improve the time complexity of number primality testing from O(sqrt(n)) to O(k * log³(n)), where k is a constant factor.

A prime number, is a natural number greater than 1 that has no positive divisors other than 1 and itself. In other words, it cannot be formed by multiplying two smaller natural numbers. Conversely, a natural number greater than 1 that is not prime is termed a composite number, meaning it can be expressed as the product of at least two smaller natural numbers.

First of all, let’s examine a straightforward implementation for testing the primality of a number with time complexity of O(sqrt(n)).

let is_prime = |val: i32| -> bool {
    if val <= 1 {
      return false;
    }
    let lim = (val as f64).sqrt() as i32;
    for i in 2..lim {
      if val % i == 0 {
        return false;
      }
    }
    true
};

But, a faster way to check for primality is to use the Miller-Rabin primality test, which has a time complexity of O(k * log³(n)), where k is the number of rounds performed by the test.

let is_prime = |val: i32| -> bool {
    if val <= 1 {
        return false;
    }
    if val == 2 || val == 3 {
        return true;
    }
    if val % 2 == 0 || val % 3 == 0 {
        return false;
    }

    let mut i = 5;
    while i * i <= val {
        if val % i == 0 || val % (i + 2) == 0 {
            return false;
        }
        i += 6;
    }

    true
};

Example: return the largest prime number that lies on at least one of the diagonals of numbers.

use std::cmp::max;

impl Solution {
    pub fn diagonal_prime(nums: &[[i32;10];10]) -> i32 { 

        let mut max_prime = 0;
        let n = nums.len();

        for i in 0..n {
            if is_prime(nums[i][i]) {
                max_prime = max(max_prime, nums[i][i]);
            }
            if is_prime(nums[n-i-1][i]) {
                max_prime = max(max_prime, nums[n-i-1][i]);
            }
        }

        max_prime
    }
}

const Numbers: [[i32; 10]; 10] = [[677088, 756354, 492839, 227615, 196834, 693183, 603728, 53790, 656614, 263593],
                             [657275, 194338, 330005, 154392, 227021, 80083, 97051, 926094, 625679, 231202],
                             [394311, 16003, 488746, 248824, 661276, 214428, 420300, 531563, 420780, 114044],
                             [802351, 209178, 275295, 270157, 827164, 742318, 841087, 212639, 417264, 28208], 
                             [265454, 75828, 165275, 458482, 300340, 517189, 595089, 624238, 336350, 715312], 
                             [879771, 520689, 173756, 870268, 725374, 706725, 685477, 336304, 737464, 594003], 
                             [136204, 569886, 245751, 474317, 660913, 20850, 678631, 875101, 413808, 732613], 
                             [881063, 318444, 114326, 667715, 64990, 879314, 862775, 559645, 827115, 655380], 
                             [962480, 235156, 670639, 730846, 993113, 628558, 445653, 506482, 213848, 16632], 
                             [432462, 439426, 523451, 499208, 814931, 937398, 768253, 999100, 644609, 378968]];
fn main() { 
    let max_prime = Solution::diagonal_prime(&Numbers);

    println!("Max prime number is {max_prime}");
}

Timing for 100 array elements

O(sqrt(n)) ................................................. 0.45s

O(k * log³(n)).............................................. 0.38s

As we can see a substantial speed improvement with the second approach of checking that the number is prime.

Thank you for accompanying me on this journey through the realm of prime numbers. All the best to you as you continue to explore, learn, and discover the wonders that the world of programming has to offer.

How Simple IDs Can Leak Your Secrets

Mykhailo Krainik — Fri, 03 Oct 2025 20:02:41 +0000

Most of us tend to overlook how we handle certain data, such as social security numbers, date of birth, or phone numbers, assuming they’re automatically treated as confidential. Seemingly ordinary elements like customer ID numbers in our database can unexpectedly lead to sensitive data leaks and can lead to unexpected complications.

For example, consider a scenario where the browser’s address bar displays “/customer/56/edit”. A customer ID that increments with each new entry might inadvertently reveal the actual size of our database to competitors. This implies that we have a minimum of 56 clients in our database. Such unintended information disclosure could potentially have adverse effects on our business.

We should grasp that any numbers displayed in the address bar or accessible via the request inspector in a browser’s developer tool can potentially lead to information leakage.

Here are some examples. What can they tell us?

{
  "user": "John Mallon",
  "payment": {
    "amount": 150.00,
    "cardNumber": "**** **** **** 1234",
  },
  "billId": "17"
}

The first impression is that everything is done safely, However, I encourage you to examine the billId more closely. It’s the same incremental ID that could potentially reveal whether there have been 17 payments specifically for John Mallon or 17 payments in the entire service.

So, what measures can we take to address this situation?

There are several approaches we can take in this situation. For instance, you could develop a custom algorithm to mask the actual database ID or opt to use UUIDs for this purpose.

A Universally Unique Identifier (UUID) is a 128-bit identifier used in computer systems to label information. UUIDs are designed to be practically unique when generated using standard methods. Unlike many other numbering systems, their uniqueness doesn’t rely on a central authority or coordination between parties. Although there’s a very slim chance of duplication, the probability is considered negligible due to the sheer uniqueness of UUIDs.

We can utilize the alphanumeric string representation of UUID characters to achieve the unique identification of data entries. UUIDs typically follow a specific pattern of 8–4–4–4–12 characters, where each segment is a combination of alphanumeric characters and hyphens.

123e4567-e89b-12d3-a456-426655440000

Let’s slightly rework our answers from the server API.

{
  "user": "John Mallon",
  "payment": {
    "amount": 150.00,
    "cardNumber": "**** **** **** 1234",
  },
  "billId": "123e4567-e89b-12d3-a456-426655440000"
}

/customer/a1f57b85-3f2c-49d9-b649-8b17cf8e2a9e/edit

As you can observe, the UUID effectively conceals the incremental value, ensuring that the actual number of data entries in the Bills or Customers table remains hidden.

HashIds

If your system cannot switch to UUID or you want to continue using IDs as an incremented number, consider using hashes.

Examples:

// JAVASCRIPT
// see: https://www.npmjs.com/package/hashids

import Hashids from 'hashids'
const hashids = new Hashids()

// Encode
const hashedId = hashids.encode(1, 2, 3) // o2fXhV
// Decode
const numbers = hashids.decode(hashedId) // [1, 2, 3]

// RUST
// see: https://github.com/charsyam/hashids_rust

use hashids::HashIds;

let ids_hash = HashIds::new_with_salt("this is my salt".to_string()).unwrap();

// Encode
let hashedId = ids_hash.encode(vec![12345]); // NkK9

// Decode
let numbers = ids.decode("NkK9".to_string()).next().unwrap(); // [12345]

// C#
// see: https://github.com/ullmark/hashids.net

using HashidsNet;
var hashids = new Hashids("this is my salt");

// Encode
var hash = hashids.Encode(12345);

// Decode
numbers = hashids.Decode("NkK9");

# Python
# see: https://pypi.org/project/hashids/

from hashids import Hashids
hashids = Hashids()

# Encode
hashid = hashids.encode(123) # 'Mj3'

# Decode
ints = hashids.decode('Mj3') # (123,)

This way, your backend continues working with simple numeric IDs, while the frontend receives a non-cryptographic, obfuscated version of the number.

{
  "user": "John Mallon",
  "payment": {
    "amount": 150.00,
    "cardNumber": "**** **** **** 1234",
  },
  "billId": "Mj3"
}

Comparing Error Handling in Rust and Go

Mykhailo Krainik — Fri, 03 Oct 2025 19:57:41 +0000

In this article, we’ll compare Rust and Go’s error handling mechanisms by taking a hands-on approach and implementing a problem in both languages. Our task is to read information from an unreliable file and show default information in case of an error. We’ll assume that our read_file function will always give an error, forcing us to handle it and return the default result from another function. Through this exercise, we'll explore the differences and similarities between the two languages and discuss the pros and cons of each approach. Let's dive in!

The first step in implementing error handling in Rust is to define an error type which can include any necessary data fields. In the example, the CustomError structure has one field called Io which can contain data of type String

enum CustomError {
    Io(String),
}

Next, you would typically implement the Display trait for the error type, which allows the error to be printed in a user-friendly way. This can be useful for debugging and user feedback.

impl fmt::Display for CustomError {
    fn fmt(&self, f: &mut fmt::Formatter) -> fmt::Result {
        match self {
            CustomError::Io(msg) => write!(f, "I/O Error: {}", msg),
        }
    }
}

In Rust, the language does not know how to automatically display your custom data structures for printing, and it is up to the programmer to provide an implementation of the std::fmt::Display trait to indicate how the data should be displayed. The Display trait provides a fmt method that takes a formatter object and outputs the data in a desired format.

CustomError::Io(msg) => write!(f, "I/O Error: {}", msg),
In the specific case of CustomError::Io(msg), it means that when a CustomError instance has the Io variant, it should be formatted as an I/O error with the message msg, using the write!() macro from Rust's standard library. The {} placeholder inside the format string is a placeholder that will be replaced by the actual message msg when the string is printed.

The next step is to define the read_file function with error handling.

fn read_file() -> Result<Bytes> {
    Err(CustomError::Io("File Not Found".to_string()))
}

In the example, the read_file() function returns a Result<Bytes, CustomError> type, indicating that it can return either a byte array Bytes or an instance of CustomError, where Result<Bytes, CustomError> is an alias of the Result<T, E = CustomError> = std::result::Result<T, E>.

It can be written in full notation as follows:

fn read_file() -> std::result::Result<Bytes, CustomError> {
    Err(CustomError::Io("File Not Found".to_string()))
}

The Result type is commonly used for error handling. This type has two type parameters, Ok and Err, and can be used to return a value or an error from a function. The error variant of Result typically includes an instance of the error type, such as CustomError.

Let’s see how these pieces come together in a full implementation. First, we call the read_file() function and handle any errors that may occur. If an error is returned, we then call the default_content() function, which returns an array of bytes. Finally, we print the resulting content after all of these steps.

use std::fmt;

enum CustomError {
    Io(String),
}

impl fmt::Display for CustomError {
    fn fmt(&self, f: &mut fmt::Formatter) -> fmt::Result {
        match self {
            CustomError::Io(msg) => write!(f, "I/O Error: {}", msg),
        }
    }
}

type Bytes = Vec<u8>;
type Result<T, E = CustomError> = std::result::Result<T, E>;

fn default_content() -> Bytes {
    b"Hello World".to_vec()
}

fn read_file() -> Result<Bytes> {
    Err(CustomError::Io("File Not Found".to_string()))
}

fn main() {
    let content = match read_file() {
        Err(err) => {
            println!("{}", err);
            default_content()
        }
        Ok(file) => file,
    };

    let content = String::from_utf8_lossy(&content);
    println!("Content: {}", content);
}

The output of the code is

I/O Error: File Not Found
Content: Hello World

Next, I will attempt to implement the same approach using Go.

package main

import (
 "fmt"
)

type CustomError struct {
 msg string
}

func (e CustomError) Error() string {
 return fmt.Sprintf("I/O Error: %s", e.msg)
}

type Bytes []byte

func default_content() Bytes {
 return []byte("Hello World")
}

func read_file() (Bytes, error) {
 return Bytes{}, CustomError{"File Not Found"}
}

func main() {
 tryFileContent, err := read_file()
 var content Bytes

 if err != nil {
  fmt.Println(err)
  content = default_content()
 } else {
  content = tryFileContent
 }

 fmt.Printf("Content: %s", string(content))
}

The output of the code is

I/O Error: File Not Found
Content: Hello World

In the Go code, everything should be pretty understandable. Instead of the Result type, Go uses the functionality of returning multiple values.

return Bytes{}, CustomError{"File Not Found"}

Let’s move on to the next step and implement the parse_line method which will validate the structure of the content based on specific rules.

KEY0 => VALUE0
KEY1 => VALUE1

fn parse_line(input: &str) -> Result<Vec<(&str, &str)>> {
    let mut pairs = Vec::new();
    for (i, line) in input.lines().enumerate() {
        let mut parts = line.split("=>").map(str::trim).filter(|t| !t.is_empty());
        match (parts.next(), parts.next()) {
            (Some(key), Some(value)) => pairs.push((key, value)),
            _ => {
                return Err(CustomError::FormatError {
                    line: i + 1,
                    msg: "Invalid format".to_string(),
                });
            }
        }
    }
    Ok(pairs)
}

The crucial aspect of this function is the Err return when a value of any element is empty. In such a scenario, parse_line will generate a new error of type CustomError::FormatError. This error will include an error message and the line number where the error occurred.

Now let’s take a look at the full implementation of the code, which includes two error handling mechanisms

use std::fmt;

enum CustomError {
    Io(String),
    FormatError { line: usize, msg: String },
}

impl fmt::Display for CustomError {
    fn fmt(&self, f: &mut fmt::Formatter) -> fmt::Result {
        match self {
            CustomError::Io(msg) => write!(f, "I/O Error: {}", msg),
            CustomError::FormatError { line, msg } => {
                write!(f, "Parsing Error: {} on the line {}", msg, line)
            }
        }
    }
}

type Bytes = Vec<u8>;
type Result<T, E = CustomError> = std::result::Result<T, E>;

fn default_content() -> Bytes {
    b"KEY0 => VALUE0 \n KEY1 => VALUE1".to_vec()
}

fn read_file() -> Result<Bytes> {
    Err(CustomError::Io("File Not Found".to_string()))
}

fn parse_line(input: &str) -> Result<Vec<(&str, &str)>> {
    let mut pairs = Vec::new();
    for (i, line) in input.lines().enumerate() {
        let mut parts = line.split("=>").map(str::trim).filter(|t| !t.is_empty());
        match (parts.next(), parts.next()) {
            (Some(key), Some(value)) => pairs.push((key, value)),
            _ => {
                return Err(CustomError::FormatError {
                    line: i + 1,
                    msg: "Invalid format".to_string(),
                });
            }
        }
    }
    Ok(pairs)
}

fn main() {
    let content = match read_file() {
        Err(err) => {
            println!("{}", err);
            default_content()
        }
        Ok(file) => file,
    };

    let content_str = String::from_utf8_lossy(&content);

    match parse_line(&content_str) {
        Ok(pairs) => {
            for (key, value) in pairs {
                println!("Content: {} = {}", key, value);
            }
        }
        Err(err) => println!("{}", err),
    }
}

To add new error handling, we simply needed to extend the functionality of the CustomError enum and the implementation of the Display trait for each error case. This illustrates how Rust’s error handling mechanism provides a concise and consistent way of dealing with errors compared to other programming languages.

In case

fn default_content() -> Bytes {
    b"KEY0 => VALUE0 \n KEY1 => ".to_vec()
}
The output of the code is

Parsing Error: Invalid format on line 2
In case

fn default_content() -> Bytes {
    b"KEY0 => VALUE0 \n KEY1 => VALUE1".to_vec()
}

The output of the code is

Content: KEY0 = VALUE0
Content: KEY1 = VALUE1

Moving on, let’s explore how this approach can be implemented in Go

package main

import (
 "fmt"
 "strings"
)

type FormatError struct {
 Line uint32
 Msg  string
}

type CustomError struct {
 Io string
}

func (e FormatError) Error() string {
 return fmt.Sprintf("Parsing Error: %v on the line %v", e.Msg, e.Line)
}

func (e CustomError) Error() string {
 return fmt.Sprintf("I/O Error: %v", e.Io)
}

type Pair struct {
 Key   string
 Value string
}

func defaultContent() []byte {
 return []byte("KEY0 => VALUE0 \n KEY1 => VALUE1")
}

func readFile() ([]byte, error) {
 return nil, CustomError{Io: "File Not Found"}
}

func parseLine(input string) ([]Pair, error) {
 lines := strings.Split(input, "\n")
 var result []Pair

 for i, line := range lines {
  line = strings.TrimSpace(line)
  if len(line) == 0 {
   continue
  }

  parts := strings.Split(line, "=>")

  key := strings.TrimSpace(parts[0])
  value := strings.TrimSpace(parts[1])

  if key == "" {
   return nil, FormatError{Line: uint32(i + 1), Msg: "Invalid format"}
  }
  if value == "" {
   return nil, FormatError{Line: uint32(i + 1), Msg: "Invalid format"}
  }

  result = append(result, Pair{key, value})
 }

 return result, nil
}

func main() {
 content, err := readFile()
 if err != nil {
  fmt.Println(err)
  content = defaultContent()
 }

 strContent := string(content)

 pairs, err := parseLine(strContent)
 if err != nil {
  fmt.Println(err)
  return
 }

 for _, pair := range pairs {
  fmt.Printf("Content: %v = %v\n", pair.Key, pair.Value)
 }
}

When implementing the same approach in Go, we will need new data structures and functions to handle new error types.

Let’s see a few examples of how it works in this code.

In case

func defaultContent() []byte {
 return []byte("KEY0 => VALUE0 \n KEY1 => ")
}

The output of the code is

Parsing error: invalid format on line 2
In case

func defaultContent() []byte {
 return []byte("KEY0 => VALUE0 \n KEY1 => VALUE1")
}

The output of the code is

Content: KEY0 = VALUE0
Content: KEY1 = VALUE1

Looking at all the examples, Rust's error handling can be more verbose, but it also allows for more expressive and informative error messages, as well as more powerful error handling mechanisms. In real-world software development, there may be errors that lead to a high level of complexity in function calls, but Rust’s easy mechanism for handling errors makes our lives as software developers happier.

How to Implement Rust’s Result Type in Dart Programming Language.

Mykhailo Krainik — Fri, 03 Oct 2025 19:38:34 +0000

According to the Stack Overflow survey, the Rust programming language has incorporated the best practices from both functional and imperative programming paradigms, drawing inspiration from languages like OCaml and Haskell. Notably, Rust’s use of the Either type sets it apart from modern languages such as Java, Python, Ruby, and Dart, which do not commonly employ this construct.

While external libraries are available to achieve similar functionality, I suggest developing a simple alternative for the Result type.

We will make use of the powerful generic functionality in Dart’s class system to achieve this goal.

class Result<T, E> {
  T? value;
  E? error;

  Result.Ok(T value) {
    this.value = value;
  }

  Result.Err(E error) {
    this.error = error;
  }
}

After implementing the Result class with the ability to handle errors, we can test it to ensure it functions as expected. The Result class consists of a generic type T and an error type E, and the Ok and Err methods are used to set the value and error types, respectively. With this class in place, we can handle errors more effectively and improve our code’s reliability.

This looks very straightforward, and in the next step, we will test this class.

To find the required element in the collection, we require a wrapper object along with a method called getRecordById. In this regard, we have implemented the RecordStore class. This class also includes the method that takes an integer searchId as input and returns a Result object. If the record is found in the collection, Result.Ok(record) is returned, else Result.Err(‘NotFound’) is returned.

class Record {
  int _id;

  get getId => _id;

  Record({required id}) : _id = id;

  String toString() => 'Record(id: $_id)';
}

class RecordStore {
  final _records;

  RecordStore({required records}) : _records = records;   

  Result<Record, String> getRecordById(int searchId) {
    for (final record in _records) {
        if (record.getId == searchId) return Result.Ok(record);
    }
    return Result.Err('NotFound');
  }
}

We can now test the implementation by attempting to retrieve the value for ID 2.

void main() {
  final store = RecordStore(
      records: List<Record>.generate(10, (genNum) => Record(id: genNum)));
  final result = store.getRecordById(2);

  if (result.value != null) {
    print(result.value.toString());
  } else {
    print(result.error);
  }
}

The output of the line print(result.value.toString()); was Record(id: 2). This is because the getRecordById method of the RecordStore class returns a Result type. If the record is found, we get Result.Ok(record), and if not, we return Result.Err(‘NotFound’). This approach is better than returning a nullable object like Record?, as it provides a more explicit way of handling errors

Suppose we modified getRecordById to return errors as an Error enum type instead of a String. The updated code would look like this:

enum Error {
  recordNotFound,
  notValidId,
}

class RecordStore {
  final _records;

  RecordStore({required records}) : _records = records;

  Result<Record, Error> getRecordById(int searchId) {
    if (searchId <= 0) return Result.Err(Error.notValidId);

    for (final record in _records) {
      if (record.getId == searchId) return Result.Ok(record);
    }
    return Result.Err(Error.recordNotFound);
  }
}

In the previous implementation, we used the Error enum to represent different types of errors that can occur when searching for a record. With the updated implementation, the getRecordById method returns a Result type. If the record is not found, Result.Err(error) is returned to indicate that an error occurred. The specific error type returned can be either Error.notValidId or Error.recordNotFound, depending on the situation. When we attempt to call store.getRecordById(-2), we receive an Error.notValidId error if the ID is invalid or an Error.recordNotFound if the record is not found. This approach can be helpful as we can use an Error enum with a switch statement to ensure that all the elements of the enum are considered in the condition

I believe we can proceed with the implementation of the following code:

result.then(ok: (record) {
    print(record.toString());
  }, err: (error) {
    switch (error) {
      case Error.recordNotFound:
        print("Nothing to display at this time.");
        break;
      case Error.notValidId:
        print(
            "Invalid ID provided. Please enter a positive integer value for the record ID.");
    }
  });

This code snippet prints the record details if it exists, and prints an appropriate error message if it does not. We use a switch statement to handle the possible error cases and provide relevant feedback to the user.

We can modify the Result class to enhance its functionality. The updated class would have the following structure:

class Result<T, E> {
  T? value;
  E? error;

  Result.Ok(T value) {
    this.value = value;
  }

  Result.Err(E error) {
    this.error = error;
  }

  dynamic then({required Function ok, required Function err}) {
    if (this.value != null) {
      return ok(value);
    }
    if (this.error != null) {
      return err(error);
    }
  }
}

With these changes, we can create instances of the Result class that can hold both a value and an error. The then method can be used to handle both cases by taking in two functions: one to handle the successful case (ok) and another to handle the error case (err). If a value is present, the ok function will be called with the value as its argument. If an error is present, the err function will be called with the error as its argument.

Here are all the code samples provided for this implementation.

enum Error {
  recordNotFound,
  notValidId,
}

class Result<T, E> {
  T? value;
  E? error;

  Result.Ok(T value) {
    this.value = value;
  }

  Result.Err(E error) {
    this.error = error;
  }

  dynamic then({required Function ok, required Function err}) {
    if (this.value != null) {
      return ok(value);
    }
    if (this.error != null) {
      return err(error);
    }
  }
}

class Record {
  int _id;

  get getId => _id;

  Record({required id}) : _id = id;

  String toString() => 'Record(id: $_id)';
}

class RecordStore {
  final _records;

  RecordStore({required records}) : _records = records;

  Result<Record, Error> getRecordById(int searchId) {
    if (searchId <= 0) return Result.Err(Error.notValidId);

    for (final record in _records) {
      if (record.getId == searchId) return Result.Ok(record);
    }
    return Result.Err(Error.recordNotFound);
  }
}

void main() {
  final store = RecordStore(
      records: List<Record>.generate(10, (genNum) => Record(id: genNum)));
  final result = store.getRecordById(-4);

  result.then(ok: (record) {
    print(record.toString());
  }, err: (error) {
    switch (error) {
      case Error.recordNotFound:
        print("Nothing to display at this time.");
        break;
      case Error.notValidId:
        print(
            "Invalid ID provided. Please enter a positive integer value for the record ID.");
    }
  });
}

In conclusion, we have seen how Rust’s Result type can be implemented in Dart to handle errors and return values in a cleaner and more concise way. By creating a custom Result class, we were able to use it to represent the success and failure of operations in a type-safe manner. We also explored how using an Error enum to represent different types of errors can make code more robust and easier to maintain. With these tools in hand, Dart developers can create more reliable and efficient code that is less prone to errors and easier support.