[Question]: Why not use Result everywhere?

[ydennisy]

@stemmlerjs hope you are well!

I would like to know why in repos you have chosen to try catch and throw Errors.

Yet in most other places you are returning a Result.fail or Result.ok.

Thanks!

[hamidgasmi]

I have the same question. Another result interface is also defined for Guard class (see below). I was expecting to reuse the Result class, instead.

export interface IGuardResult {
  succeeded: boolean;
  message?: string;
}

[imcyee]

Because repo implementation is using library that is created by others.

When-to-throw-errors-purposefully B: When we encounter errors that we don't expect or know how to deal with. These are errors that really mess up what we were trying to do and can be caused by an infinite possibility of things that we didn't expect or assume would happen:

database connectivity issues
code typos
null pointer errors (sometimes)
out of memory

[hamidgasmi]

Agree for the repo. Thanks @imcyee. I am still wondering why we have multiple result classes/interfaces.

[imcyee]

I think you definitely can implement it with Result class. Don't see any problem with it. Instead of {succeeded:boolean} you will have Result.ok/fail(), from what I learned from his blog, I think this one you have choice to choose between simple json and Result class.

[stemmlerjs]

In the name of consistency, I think it's a good idea to use the same construct everywhere. When I first implemented the Guard class, I was just using a technique called programming by wishful thinking to design an API that was human-friendly to use. I'm glad you spotted this. Just refactored it to rely on Result here.

Thanks y'all.