Forem: Sandu Bogdan

(ShowDev) JavaScript Exceptions: What they do right, and what they do wrong

Sandu Bogdan — Wed, 29 Apr 2026 19:11:45 +0000

All languages have, so far, reached a certain point in their development: error handling. JavaScript, like most languages, chose try-catch statements. This way of error handling, however, is often worse than it is good, despite doing some things right.

What do they do right?

Back when programs were simple and linear, Exceptions were a great way of error handling: they force the programmer to handle any possible errors, or else the program crashes.

So, all developers had to either handle possible errors or risk their program crashing out of nowhere. This was by purpose — it was a simple yet efficient way to get developers to handle issues.

What do they do wrong?

While try-catch used to be a great way of handling errors, the more branching and complexity you add, the more annoying it is to use it.

Let’s take this scenario:

async function doSomething(key) {
    const resource = await fetch("/v2/data");  // Can fail on network error
    const data = await resource.json();  // Can fail if JSON is invalid
    const value = data[key];
    return value;
}

This small example can throw two different errors. Let’s see how you would normally handle them:

async function doSomething(key) {
    let resource;
    try {
        resource = await fetch("/v2/data");
    } catch {
        console.error("Failed to get resource.");
        return undefined;
    }
    let data;
    try {
         data = await resource.json();
    } catch {
        console.error("Failed to parse response JSON.");
        return undefined;
    }

    const value = data[key];
    return value;
}

So, just to fetch some data and retrieve a value, we need two try-catch statements.

Let's rewrite that with a single try-catch statement:

async function doSomething(key) {
    try {
        const resource = await fetch("/v2/data");
        const data = await resource.json();

        const value = data[key];
        return value;
    } catch {
        console.error("An error occured.");
        return undefined;
    }
}

While this works, the error handling here is far too broad for modern codebases.

The solution

So, exceptions are messy. The solution? — Errors As Values (yes i typed that em-dash by hand).

Let's see what that exact same code would look like if fetch(), .json(), and key indexing all used Errors As Values instead of throwing an Error.

async function doSomething(key): [unknown, Error | null] {
    const resource = await fetch("/v2/data");
    if (!resource)
        return [undefined, new Error("Failed to fetch resource")];

    const data = await resource.json();
    if (data === undefined)
        return [undefined, new Error("Failed to parse response JSON")];

    const value = data[key];
    return [value, null];
}

const data = await doSomething("myKey");

if (data[0])
    console.log(data[0]);
else
    console.error(`New Error: ${data[1]}`);

Notice how much shorter it is, while still allowing the developer to handle errors?

A good example of Errors-As-Values is Effect, which, despite its steep learning curve, provides a great implementation of Errors-As-Values.

Not everyone is willing to learn an entirely new framework, though (especially not one that involves whatever yield* myFunc() is). Good news is: you don't need to; you can very easily implement your own basic version of this. Here is an example:

type ExpectedType<T, E> = {success: true, data: T} |
        {success: false, data: E};

const ok = (v) => ({success: true, data: v});
const fail = (e) => ({success: false, data: e});

async function doSomething(key): ExpectedType<unknown, Error> {
    const resource = await fetch("/v2/data");
    if (!resource[0])
        return fail(resource[1]);

    const data = await resource.json();
    if (!data[0])
        return fail(data[1]);

    const value = data[key];
    return ok(value);
}

const data = await doSomething("myKey");

if (data.success)
    console.log(data[0]);
else
    console.error(`New Error: ${data[1]}`);

(ShowDev) Writing a makeshift solution

Just so I could have a simple solution to this problem, I wrote ErrorsAsValuesTS — a library designed specifically for Errors-As-Values error handling.

Here's an example of the above code with this library:

import { Expected } from "errorsasvaluests";

async function doSomething(key): unknown {
    const resource = await fetch("/v2/data");

    const data = await resource.json();

    const value = data[key];
    return value;
}

const value = await Expected<unknown, Error>.run(doSomething, ["myKey"]).onError(
    e => { console.error(`New Error: ${e}`); }

if (value !== undefined)
    console.log(value);
);

This code snippet runs doSomething("myKey"). If any error is thrown, value becomes undefined and that arrow function is called. If no error is thrown, value becomes the returned data. Simple enough, yet robust. No more reading source code to see what errors can be thrown (they are now typed), no more forgetting to handle errors.

So why doesn't JavaScript throw away Exceptions?

Simple answer — it can't.

Long answer — all existing infrastructure running on JavaScript/TypeScript already assumes, and relies on, Exception-based error handling. All of the existing Node programs, all of the existing websites, they all assume Exception-based error handling. If JavaScript suddenly moved away from Exceptions, years of backwards compatibility would be lost, and the costs of switching to a new method of handling errors would be massive.

Conclusion

Exceptions work for simple, linear programs, but they are severely limited in real-world applications. They are still useful, however, for backwards-compatibility purposes.

I am not saying JavaScript is bad for having used Exceptions, nor am I implying anything bad about JavaScript itself. Instead, exceptions shouldn't generally be used by libraries, modules or normal codebases unless there is a really good reason for it, and you should instead prefer using simple Errors-As-Values implementations or just going for Effect (or an errno()-like implementation, if you wish). How you implement Errors-As-Values doesn't matter; if done properly, it will make your codebase easier to work with.

Additionally, Exceptions remain a good idea for actually exceptional issues that shouldn't normally appear, but are arguably worse for structured control flow or expected errors.

Making a hello-world program in kernel space

Sandu Bogdan — Mon, 27 Apr 2026 19:26:52 +0000

Notes

This article assumes a single-core RV64I RISC-V CPU with OpenSBI firmware.

Getting booted by OpenSBI

OpenSBI (the most common firmware used by RISC-V machines) typically loads itself at 0x80000000, anything below being reserved for MMIO¹ devices. To ensure your kernel's load address doesn't overlap with OpenSBI code, you would typically load your kernel at an address such as 0x80200000 (Bonus: as your kernel is 2MB-aligned, when you set up paging, you can use large pages² to minimize TLB misses, which makes code faster).

1: MMIO, or Memory-mapped I/O, is the protocol through which you communicate with external devices via writing to memory. While CPU architectures such as x86-64 use port I/O (dedicated `inb`/`outb`) instructions, RISC-V prefers MMIO for simplicity.

2: Pages generally come in sizes of 4KB, 2MB, and 1GB. These sizes are enforced by the MMU (Memory Management Unit). Large pages are 2MB pages, often used for large memory regions in order to minimise TLB misses.

Preparing to jmp into C code

Unfortunately, we have to set some things up ourselves via Assembly until we can run C code.

Setting up the stack

Setting up the stack is fairly simple. First, we have to define a section that we can use for the stack:

.section .stack
.global stack_top
.balign 16  # Use 128-bit alignment (yes this is necessary)
.space 16384  # 16KB stack
stack_top:

We're going to define the stack section later, in our linker file.

Preparing an entry stub in Assembly

This is what OpenSBI will jmp to.

.section .text
.global _start
.extern stack_top

.extern kernel_main

.section .text.entry  # Practically tell the linker to place this function at the start of kernel memory
.balign 8  # 64-bit alignment
_start:
    # Zero out the .bss section, 32 bits at a time
    la t0, __bss_start
    la t1, __bss_end
    bss_loop:
        bge t0, t1, bss_done
        sw zero, 0(t0)
        addi t0, t0, 4
        j bss_loop
    bss_done:

    # Load the stack pointer
    la sp, stack_top

    call kernel_main  # This is what jumps to our C code
# If kernel_main returns, spin indefinitely
spin:
    j spin

Making the linker file

This is going to look a lot like dark magic, but I am going to explain as much as possible using comments.

OUTPUT_ARCH(riscv)  /* Tell ld that we want to use RISC-V */
ENTRY( _start )  /* Tell ld that our program should start at _start */

MEMORY
{
    RAM (rwxa) : ORIGIN = 0x80200000, LENGTH = 1G  /* This is where usable memory starts. rwxa makes it readable, writable, executable, and allocateable */
    STACKRAM (rw) : ORIGIN = 0xc0200000, LENGTH = 16K  /* Separate the stack from other data (practically inserting guard pages if you ever set up paging). By keeping it non-allocateable, leftover memory from .bss can't flow into STACKRAM */
}

SECTIONS
{
    . = 0x80200000;  /* Remember that magic load address? */
    .text : {
        /* This is our code */
        *(.text.entry)  /* make sure _start is first */
        *(.text .text.*)
    } > RAM

    .rodata : {
        /* This is our read-ony data */
        . = ALIGN(16);
        *(.rodata .rodata.*)
    } > RAM

    .data : {
        . = ALIGN(16); /* Indeed more alignment (RISC-V faults on misaligned access) */
        *(.data .data.*)
    } > RAM

    /* Uninitialised variables */
    .bss : {
        . = ALIGN(16);
        __bss_start = .;  /* Tell it where to start */
        *(.bss .bss.*)
        *(COMMON)
        . = ALIGN(4);
        __bss_end = .;  /* Tell it where to end */
    } > RAM

    /* Our stack section from earlier */
    .stack (NOLOAD) : {  /* (NOLOAD) makes the .stack section not be loaded from within the binary */
        *(.stack)
    } > STACKRAM
}

Making a C entrypoint

Now that we got all the setup issues out of the way, let's make a basic hello world program in C.

Making an UART driver

// uart.h
typedef unsigned char uchar;

void uart_putc(uchar c);
void uart_puts(const uchar* s);

// uart.c
#include <stdint.h>
#include "uart.h"

#define UART_BASE 0x10000000  // Note: This can change between machines

#define UART_THR  0x00 // Write Offset
#define UART_LSR  0x05 // Is it occupied?

#define LSR_TX_IDLE 0x20

#define UART_REG(reg) ((volatile uint8_t *)(UART_BASE + reg))  // A helper to get UART addresses as volatile (writes immediately)

void uart_putc(uchar c) {
    // Wait until we can write to UART again
    while ((*UART_REG(UART_LSR) & LSR_TX_IDLE) == 0);

    __asm__ volatile("fence o, o" :::"memory");

    *UART_REG(UART_THR) = c;
}

void uart_puts(const uchar *s) {
    while (*s) {
        uart_putc(*s);
        s++;
    }
}

(Finally) a hello world program

#include "uart.h"

void kernel_main() {
    uart_puts("Hello from Kernel World!");
}

Congrats! You've now written your first hello world program in kernel space, with only ~100 lines of code.

You can now run it in a QEMU VM to see if it works! Make sure to give it something like 2GB of RAM, or to update the linker script for a lower ram requirement.

If you're stuck, here is how I built and ran it:

riscv64-unknown-elf-gcc main.c uart.c entry.S stack.S -T linker.ld -o kernel.elf -mcmodel=medany -ffreestanding -nostdlib -nostartfiles
qemu-system-riscv64 -machine virt   -cpu rv64   -m 2G   -nographic   -bios default   -kernel kernel.elf

Next Steps

Now that you have a Hello World program up and running, here are a few challenges left for the reader:

Making a printf() implementation
Adding support for paging
Adding a basic fault handler