Three Ways to Handle Exceptions with Async Functions

Javascript exceptions shouldn’t be thrown when an IO  to error occurs. Instead, helpful messages should be sent your your logger system AND to the user.

Method 1: Try/Catch

Traditionally, these exceptions are handled using Try/Catch blocks, but those can easily make your code unreadable. For example,

Method 2: Catch Callback

Method 3: Custom Exception Wrapper

This method is inspired by Dima Grossman’s post.

Which to Choose?

Method 1 is just plain yuck. Method 2 is decent, I prefer Method 3 for readability.

What’s with Redux, ReduxSauce, Thunk, and Sagas?

What is Redux?

A library to create and manage data objects (aka state objects) based on the flux pattern.


Are requests to a store to take an action.

{ type: ADD_TODO, text: ‘Build my first Redux app’}

Action Types

An enum of allowable action types.


Are handler functions for actions that apply the action payload.

myReducer = (state, action) => nextState


Is a library to make Redux more DRY. In doing so though, it makes the code less readable imo.

Thunk and Sagas

Calls to actions are synchronous. This means that action handlers cannot fetch data or have side effects. Thunk and Sagas solve this desire.

Reasons for: More powerful Redux can handle most of your biz logic
Reasons against: If not done carefully, you will end up with Redux spaghetti


Thunk is an extended reducer which can (1) return a promise, and (2) actions are allowed to be called from within the promise (aka side-effects). For example, you can have an action which first sets a loading field = true in the store, fetches data, then updates the store when done.


Sagas is like Thunk, but allows for action handling to be interrupted using generators

Further Reading


How to access object attributes based on a variable in Typescript

Typescript is obscurely particular with accessing attribute keys on objects that lack a generic signature. Adding generic signatures reduces type-safety though.

Here’s a Typescript-friendly way to verify an attribute exists in an object, and then access that attribute.

This post originally posted at

How and when to use python’s lambda

There is a long running debate in python land of the usefulness of the lambda function, and I usually air on the side of avoidance.  However, for simple occasions it can make for cleaner code.

The python docs are essential for quick reference, but sometimes they skimp on obscure features.  Lambda is one of those features.

In a nutshell, lambda is the inline function creator for python. In other languages, inline functions often look like this:

myFunction is a function, and myFunction(1,2)=3.  That makes a lot of sense! myFunction can similarly be defined in python using lambda:

myFunction = lambda arg1,arg2:  arg1+arg2

It’s true that this syntax requires less typing, but at the cost of readability.  In case you were wondering, here is a good example of when to use it.

Without lambda:

With lambda:

Head caution though, because readability goes out the window whenever the lambda expression gets to complicated.

When not to use lambda: