DEV Community: Patrick Roza

When to return a Result.Error and when to throw an Exception?

Patrick Roza — Wed, 12 Jun 2019 17:45:00 +0000

In the previous part I introduced the Result class as a means of control flow and error handling. Now I will focus on when to use the Result class to return an Error, and when to throw instead.

There appears to be quite some different opinions on the subject:

Always throw an Error
Always throw errors and then only wrap them when you want to handle them
Only return recoverable errors, throw the rest
Return expectable errors, throw (or pass through) the rest.
Return every error, never throw. (Wrap any library error)

I am mostly in Camp 4, although I think 3 and 4 actually mean the same thing, most of the time. As always, it depends on the use case.

I would generally return: Domain errors and certain Infrastructure errors

SoldOut, RoomAlreadyBooked, PaperJammed, InvalidProductCode, CodeAlreadyRedeemed, PaymentMethodFailed
ValidationError, InvalidStateError, ForbiddenError, AuthenticationRequiredError
APIError/DBError: RecordNotFound, RecordAlreadyExists, (Optimistic)LockError, CouldNotAcquireLockError, ConnectionError, RemoteServiceError

I would throw exceptions (panics):

Programmer errors:

ArgumentException
NullException
DivideByZeroException

Corruption errors, e.g: SerializationException

The runtime will also throw various errors, for instance in case of StackOverflow or OutOfMemory.Such errors should abandon the current flow, and raise an exception, probably caught at the highest level, usually for error logging.

In the end, it depends on what you're building.

Catch & Wrap ‘all the tings’?

Does this mean you should catch and wrap all third party errors? No, it follows the same principals; if it falls into expectable errors like one that represents api call status codes like 400 or 404, or e.g a database record not found; wrap them.

Why return instead of throw

a technique that allows you to capture errors elegantly, without contaminating your code with ugly conditionals and try/ catch statements.

From the book “Domain modeling made functional”; A great read, really recommended!

try/catch/finally is verbose, indenting/nesting at least 1 scope deep, often also leading to multiple levels deep (within 1 or more functions)
Errors become part of the return type signature; automatic documentation, and compiler assistance when missing to handle one
It enables composability
Throwing errors is expensive (stack traces etc), while for the error cases you would return, generally I see no use for stack traces. Now I’ll be the first to say: don’t prematurely optimize, but if you can design your application from the ground up to be performant, even in the expectable error cases; that’s great.

As a side note, in javascript:

There is no ‘beautiful’ built-in way to handle different error types differently, other than if statements or switch, unlike e.g in C# or Python.
There is no ‘beautiful’ built-in way to document the errors that may occur, and have type-safety for them, unlike in e.g Java.

Other examples of implementations that favor return status over Exceptions

fetch : The fetch implementation will only throw on a Network Error. It will use an ok Boolean that will be false on a status code > 400. It isn’t as elegant as the Result class though.
Promise : once resolved or rejected; either success or error. Has the benefit of await support however.

Relationship to "Checked" Exceptions

https://stackoverflow.com/questions/613954/the-case-against-checked-exceptions

https://softwareengineering.stackexchange.com/questions/150837/maybe-monad-vs-exceptions

Perhaps summated as:

With great power comes great responsibility

I think the difference is that Checked exceptions are a forced concept , but Result can be an application level decision you make, you opt-in.

In fact, if you don't want to handle a Result.Error, you can just let it bubble up, there's no requirement to handle it, unless you explicitly decide "this is the place I want to handle each and every exception in a certain way", and e.g use Typescript's "exhaustive switch block" or similar.

Finally, in Typescript and F# there are Union types that help you "fold" errors into higher order ones, unlike with Checked exceptions in e.g Java.

Violation of the Open/Closed Principle?

https://stackoverflow.com/questions/54882275/do-checked-exceptions-violate-the-open-closed-principle

OCP appears to apply to modules, not methods. Also I think that if you add a new exception, you are more "silently" breaking the contract. At least Return error types don't lie ;-)

Error handling samples

Handle Success, or Error case

doSomething()
  .pipe(match(
    value => ctx.body = value,
    err => ctx.statusCode = 500,
  ))

Fallback to a default value

const result = doSomething()
  .pipe(orDefault(“some-default-value”))
// if doSomething() fails, use “some-default-value” instead.

High level REST api error handler (more elegant ideas welcome!)

if (err instanceof RecordNotFound) {
  ctx.body = { message }
  ctx.status = 404
} else if (err instanceof CombinedValidationError) {
  const { errors } = err
    ctx.body = {
    fields: combineErrors(errors),
    message,
  }
  ctx.status = 400
} else if (err instanceof FieldValidationError) {
  ctx.body = {
    fields: { [err.fieldName]: err.error instanceof CombinedValidationError ? combineErrors(err.error.errors) : err.message },
    message,
  }
  ctx.status = 400
} else if (err instanceof ValidationError) {
  ctx.body = { message }
  ctx.status = 400
} else if (err instanceof InvalidStateError) {
  ctx.body = { message }
  ctx.status = 422
} else if (err instanceof ForbiddenError) {
  ctx.body = { message }
  ctx.status = 403
} else if (err instanceof OptimisticLockError) {
  ctx.status = 409
} else if (err instanceof CouldNotAquireDbLockError) {
  ctx.status = 503
} else if (err instanceof ConnectionError) {
  ctx.status = 504
} else {
  // Unknown error
  ctx.status = 500
}

Which would be accompanied by a catch-all exception handler for status 500, and logging:

try {
  // execute the workflow
  // handle success and error result cases
} catch (err) {
  logger.error(err)
  ctx.status = 500
}

Source

As always you can also find the full framework and sample source at patroza/fp-app-framework

What's Next

Next in the series, I plan to explore my ideal vision of the future, once we receive pipe operator |> and improved Generator typing support in Typescript ;-)

More advanced pipeline composition

Patrick Roza — Mon, 10 Jun 2019 10:00:00 +0000

When we add more functional composition tools to our belt, we can start composing usecase pipelines that are both terse and descriptive.

Operators

From previous article: map: (value => newValue) => Result<newValue, ...>
flatMap: (value => newResult) => newResult
toTup: (value => newValue) => readonly [newValue, value]
tee: (value => any) => Result<value, ...>
resultTuple: (...[Result<..., ...>]) => Result<readonly [value, value2, ...], error[]>

Sample

type CreateError = CombinedValidationError | InvalidStateError | ValidationError | ApiError | DbError

// ({ templateId: string, pax: Pax, startDate: string }) => Result<TrainTripId, CreateError>
pipe(
  flatMap(validateCreateTrainTripInfo), // R<{ pax: PaxDefinition, startDate: FutureDate, templateId: TemplateId}, CombinedValidationError>
  flatMap(toTup(({ templateId }) => getTrip(templateId))), // R<[TripWithSelectedTravelClass, { pax... }], ...>
  map(([trip, proposal]) => TrainTrip.create(proposal, trip)), // R<TrainTrip, ...>
  tee(db.trainTrips.add), // R<TrainTrip, ...>
  map(trainTrip => trainTrip.id), // R<TrainTripId, ...>
)

The validateCreateTrainTripInfo function:

// ({ templateId: string, pax: Pax, startDate: string}) => Result<({ pax: PaxDefinition, startDate: FutureDate, templateId: TemplateId }), CombinedValidationError>
pipe(
  flatMap(({ pax, startDate, templateId }) =>
    resultTuple(
      PaxDefinition.create(pax).pipe(mapErr(toFieldError("pax"))),
      FutureDate.create(startDate).pipe(mapErr(toFieldError("startDate"))),
      validateString(templateId).pipe(mapErr(toFieldError("templateId"))),
    ).pipe(mapErr(combineValidationErrors)),
  ),
  map(([pax, startDate, templateId]) => ({
    pax, startDate, templateId,
  })),
)

Both are taken from usecases/createTrainTrip.ts

This validator facilitates domain level validation, not to be confused with REST level DTO validation. It prepares the validated DTO data for input to the domain factory TrainTrip.create. These domain rules are neatly packaged in the Value objects FutureDate and PaxDefinition, reducing complexity and knowledge creep in the factory.

Again, if tc39 proposal-pipeline-operator would land, we can write more terse and beautiful code.

CombinedValidationErrors

We're wrapping each ValidationError into a FieldValidationError, so that we have the name of the field in the error context, then at the end we combine them into a single error, which can be easily examined and serialized to e.g JSON on the REST api to be consumed and examined by the client.

e.g:

if (err instanceof CombinedValidationError) {
  ctx.body = {
    fields: combineErrors(err.errors),
    message,
  }
  ctx.status = 400
}

const combineErrors = (ers: any[]) => ers.reduce((prev: any, cur) => {
  if (cur instanceof FieldValidationError) {
    if (cur.error instanceof CombinedValidationError) {
      prev[cur.fieldName] = combineErrors(cur.error.errors)
    } else {
      prev[cur.fieldName] = cur.message
    }
  }
  return prev
}, {})

Source

As always you can also find the full framework and sample source at patroza/fp-app-framework

What's Next

Next in the series, I plan to examine the question: "When to return errors, and when to throw them?"

Result: Composition and Error handling

Patrick Roza — Sun, 09 Jun 2019 12:30:00 +0000

We can improve our error handling and composition by leveraging a Result class and several other tools from the functional programming world.

Instead of throwing errors, we wrap our results. Either the Result is an Error value, or a Success value, in the process documenting the possible errors. Callers must first examine and unwrap the Result, handling either the Success or Failure case. Paving the way for more functional programming and composition.

For a more complete introduction to the Result class and Railway Oriented Programming:

For implementations check GitHub #railway-oriented-programming; ROP in many programming languages (Python/Go/Java/C#/F# etc)

In these series I will share my findings during my (exciting) journey.

Imperative sample

const r = doSomeAction() // Result<string, SomeVariableIsInvalid | ServiceUnavailableError>
if (r.isErr()) { // r: Error<SomeVariableIsInvalid | ServiceUnavailableError>
  if (r.error instanceof SomeVariableIsInvalid) {
    ctx.body = r.error.message
    ctx.statusCode = 400
  } else {
    ctx.statusCode = 500
  }
  return
}
// r: Ok<string>
ctx.body = r.value
ctx.statusCode = 200

doSomeAction could be implemented like:

function doSomeAction(): Result<string, SomeVariableIsInvalid | ServiceUnavailableError> {
  if (!someVariableIsValid) {
    return err(new SomeVariableIsInvalid("some variable is not valid")
  }
  if (!isServiceAvailable()) {
    return err(new ServiceUnavailableError("The service is currently unavailable")
  }

  return ok("success response")
}

Functional sample

doSomeAction() // Result<string, SomeVariableIsInvalid | ServiceUnavailableError>
  .map(value => {
    ctx.body = value
    ctx.statusCode = 200
  })
  .mapErr(error => {
    if (error instanceof SomeVariableIsInvalid) {
      ctx.body = error.message
      ctx.statusCode = 400
    } else {
      ctx.statusCode = 500
    }
  })

All "operators" must live on the Result object and thus extension is harder. (This is similar to how for instance RxJS started)

Functional Composition

doSomeAction() // Result<string, SomeVariableIsInvalid | ServiceUnavailableError>
  .pipe(
    map(value => {
      ctx.body = value
      ctx.statusCode = 200
    }),
    mapErr(error => {
      if (error instanceof SomeVariableIsInvalid) {
        ctx.body = error.message
        ctx.statusCode = 400
      } else {
        ctx.statusCode = 500
      }
    })
  )

The operators are now just functions, easy to extend and roll our own ;-) (RxJS v5.5 users may see some similarities here)

Data last

const pipeline = pipe(
  map(value => {
    ctx.body = value
    ctx.statusCode = 200
  }),
  mapErr(error => {
    if (error instanceof SomeVariableIsInvalid) {
      ctx.body = error.message
      ctx.statusCode = 400
    } else {
      ctx.statusCode = 500
    }
  })
)

pipeline(doSomeAction())

So pipeline is now reusable. If only tc39 proposal-pipeline-operator would land soon, so that we get syntactic sugar that will hide some boiler plate and syntactic noise :)

Building on top

Further decomposition into separate functions, so that they become re-usable, or to separate the levels of abstraction so that the pipeline becomes easier to read.

const writeSuccessResponse = value => {
  ctx.body = value
  ctx.statusCode = 200
}

const writeErrorResponse = error => {
  if (error instanceof SomeVariableIsInvalid) {
    ctx.body = error.message
    ctx.statusCode = 400
  } else {
    ctx.statusCode = 500
  }
}

const pipeline = pipe(
  map(writeSuccessResponse),
  mapErr(writeErrorResponse)
)

Further decomposition:

const writeSuccessResponse = value => {
  ctx.body = value
  ctx.statusCode = 200
}

const writeDefaultErrorResponse = error => {
  ctx.statusCode = 500
}

const writeSomeVariableIsInvalidErrorResponse = error => {
  if (error instanceof SomeVariableIsInvalid) {
    ctx.body = error.message
    ctx.statusCode = 400
  }
}

const pipeline = pipe(
  map(writeSuccessResponse),
  mapErr(writeDefaultErrorResponse),
  mapErr(writeSomeVariableIsInvalidErrorResponse),
)

Perhaps another option:

const mapErrIf = (errorHandler: error => void, predicate: error => boolean) => 
  error => {
    if (!predicate(error)) { return }
    errorHandler(error)
  }
}
// usage
mapErrIf(_ => ctx.statusCode = 400, error => error instanceOf SomeVariableIsInvalid)

And there are of course many other options and forms of composition, let that be the reader's excercise ;-)

Framework and Sample code

I'm working on an application framework while exploring these topics, that leverages the pipeline composition extensively, Sample app included!

Source code:

fp-app framework
- sample app
- neverthrow pipe extensions
- Uses neverthrow fork (forked from gDelgado14/neverthrow)

What's Next

Next in the series, I plan to introduce the more advanced concepts like flatMap, toTup, tee and others :)

Component vs Prop drilling in React

Patrick Roza — Sat, 08 Jun 2019 14:00:00 +0000

Recently, often the question is asked if Hooks and Context replaces Redux. It is more a question of do you need Redux, and perhaps how Hooks and Context can help you write cleaner, more functional, more composable code.

Dan Abramov

@dan_abramov

@NgozikaDanny Hooks by themselves are an alternative way to write and reuse logic between components. So they’re not any more “alternative” to Redux than classes. They’re just a way to write and compose code.

The question of whether you need Redux seems unrelated to Hooks to me.

11:16 AM - 16 Apr 2019

0 9

I stumbled upon these topics in:

In these series, I will try to make a point why I think you can achieve most usecases without needing Redux, and perhaps how Hooks and Context may help you with that.

Let's first examine what is often recommended as alternative to Redux:

A container component that centralizes the state, and then leverages "prop drilling" to pass props down to all child components. Creating coupling between the components, sometimes multiple levels deep.
Multiple components that manage their own state and upgrade to Context/Provider API once state is more shared. Continueing "prop drilling". Also as clients sometimes have a hard time to make up their mind, it may lead to a lot of jumping around of where the state should live.

Improvement 1: Component Drilling instead of Prop Drilling

A prop drilling sample:

const SomeScreen = ({ someAction, someProp, someOtherProp, someOtherChildProp }) => (
  <div>
    <SomeComponent someProp={someProp} />
    <SomeOtherComponent
      someOtherProp={someOtherProp}
      someOtherChildProp={someOtherChildProp}
      action={someAction}
    />
  </div>
)

const SomeOtherComponent = ({action, someOtherProp, someOtherChildProp}) => (
  <div>
    <SomeOtherChildComponent
      prop={someOtherChildProp}
      action={action}
    />
  </div>
)

What makes this prop drilling is the fact that SomeOtherComponent takes someOtherChildProp and someAction, which are actually props of the SomeOtherChildComponent.

Now with component drilling:

const SomeScreen = ({ someAction, someProp, someOtherProp, someOtherChildProp }) => (
  <div>
    <SomeComponent someProp={someProp} />
    <SomeOtherComponent someOtherProp={someOtherProp}>
      <SomeOtherChildComponent
        someProp={someOtherChildProp}
        action={someAction}
      />
    </SomeOtherComponent>
  </div>
)

Here we stopped making SomeOtherComponent responsible to pass the props for SomeOtherChildComponent. Of course this moves the coupling from SomeOtherComponent to the Screen instead. Better; it lives closer to the definition, there are less players involved in coupling.

Improvement 2: State in Hooks/HOCs, so that it can be easily upgraded/downgraded from shared to local state etc.

The goal is to decouple the 'detail' if state is local, shared, or global. Also, the source of the state will be abstracted (imagine that some of the state comes from REST/GraphQL/localStorage it doesn't matter)

// written as hooks, but can be written as HOCs as well
const useSomeProp = () => {
  const someProp = // ...
  return { someProp }
}
const useSomeOtherProp = () => {
  const someAction = // ...
  const someOtherProp = // ...
  const someOtherChildProp = // ...
  return { someAction, someOtherProp, someOtherChildProp }
}

const SomeScreen = () => {
  const { someProp } = useSomeProp()
  const { someAction, someOtherProp, someOtherChildProp } = useSomeChildProp()
  return (
    <div>
      <SomeComponent someProp={someProp} />
      <SomeOtherComponent someOtherProp={someOtherProp}>
        <SomeOtherChildComponent
          someProp={someOtherChildProp}
          action={someAction}
        />
      </SomeOtherComponent>
    </div>
  )
}

As you can see, the props now come from 2 hooks (which could be written as HOCs as well)

Now imagine that we want to use the same state of useSomeOtherProp elsewherec:

const SomeContext = createContext()
const useSomeOtherProp = () => {
  const someAction = // ...
  const { someOtherProp, someOtherChildProp } = useContext(SomeContext)
  return { someAction, someOtherProp, someOtherChildProp }
}

// Wrap the `<SomeContext.Provider value={...state} />` around the `SomeScreen`

Now imagine that SomeOtherComponent has to become more nested, or used in other places:

const SomeOtherComponent = () => {
  // moved from SomeComponent
  const { someAction, someOtherProp, someOtherChildProp } = useSomeChildProp()
  return (
    <div>
      <h1>{someOtherProp}</h1>
      <SomeOtherChildComponent
        someProp={someOtherChildProp}
        action={someAction}
      />
    </div>
  )
}

// Move the <SomeContext.Provider where-ever it makes sense to be able to access the shared state.

Slots

Of course component drilling does not mean only children, you can also drill components through props ;-)

const SomeOtherComponent = ({ children, left, right }) => (
  <div>
    <div>{left}</div>
    <div>{children}</div>
    <div>{right}</div>
  </div>
)

// Usage
<SomeOtherComponent
  left={<SomeChildComponent1 action={someAction} />}
  right={<SomeChildComponent2 ... /> }
>
   Some center content
</SomeOtherComponent>

In closing

There's of course more to it, more trade-offs to consider, room for optimizations etc. But we can address them once they become relevant. That's the beauty of a flexible architecture; make things just flexible/plugable enough so that once changed requirements come (and they will), you can respond to them quickly.

DEV Community: Patrick Roza

When to return a Result.Error and when to throw an Exception?

Catch & Wrap ‘all the tings’?

Why return instead of throw

Other examples of implementations that favor return status over Exceptions

Relationship to "Checked" Exceptions

Violation of the Open/Closed Principle?

Error handling samples

Source

Other reads

What's Next

More advanced pipeline composition

Operators

Sample

CombinedValidationErrors

Source

What's Next

Result: Composition and Error handling

Imperative sample

Functional sample

Functional Composition

Data last

Building on top

Framework and Sample code

What's Next

Further reading

Component vs Prop drilling in React

Improvement 1: Component Drilling instead of Prop Drilling

Improvement 2: State in Hooks/HOCs, so that it can be easily upgraded/downgraded from shared to local state etc.

Slots

In closing