ddd-forum icon indicating copy to clipboard operation
ddd-forum copied to clipboard

[Question]: Usage of left/right monad & try/catch

Open ydennisy opened this issue 3 years ago • 2 comments

@stemmlerjs sorry but one more question :)

I was wondering why in the DDD forum, solidbook and your blog where you are using left/right there is still a lot of try/catch is the purpose not for the functional monad to remove the need to use try/catch?

Example:

  • https://github.com/stemmlerjs/ddd-forum/blob/master/src/modules/forum/useCases/comments/replyToPost/ReplyToPost.ts#L47
  • https://github.com/stemmlerjs/ddd-forum/blob/master/src/modules/forum/useCases/comments/replyToPost/ReplyToPostController.ts#L27

ydennisy avatar Apr 03 '22 09:04 ydennisy

Hi @ydennisy. So yes, for the controller, you're right, we don't need those extra try/catch blocks. My mistake. Those can be removed. Since we're already using the monad to handle application errors in the use case and we're already wrapping the possibility of anything erroring out in the use case with a root try/catch, that one in the controller is superfluous. I'll clean that up in a PR.

With respect to this line, it's good you raised it. For background knowledge, the previous design decision was to throw an error if we attempt to find something from a repo and it's not there. Why did I do that? To mitigate needing to put more effort into repository design. Regardless, there are actually two issues with this code:

  1. This line actually has two reasons for failing (MemberNotFound and PostNotFound). We only represent one of those potential errors.
  2. It's not very explicit or intention-revealing via the contract of the repository interface that this could throw an error. Better design would be to not merely throw an error, but to change the contract of the return value to be something which can be easily

Problem 1 is an easy fix. If you'd like to get into it, we can discuss 2.

Here's the current contract/signature.

// the concept of various possible return results aren't modelled here
getPostBySlug (slug: string): Promise<Post>;

What are all the things that could go wrong when attempting to do this?

Application-related

  • post not found

Database-related

  • database connection lost
  • table not found
  • and so on

Perhaps we can create a generic repository response object?

stemmlerjs avatar Apr 23 '22 23:04 stemmlerjs

@stemmlerjs thanks for your reply!

On point 1 - yeah that is an easy fix, agreed that it can just be removed, also the BaseController has a try/catch.

On point 2 - why do you think we could not use the Result class inside of the repository?

There is a further point 3 - which is what is the point of the left / right monads, they seem to only exist to left us know if they have succeeded or failed, which the Result class already can handle.

ydennisy avatar May 04 '22 13:05 ydennisy