Think about removing happyAttempt

[theangrydev]

Remembering that this library is supposed to be about two tracks flows, it doesn't really make sense to have a happyAttempt method at all, because at that point there is only one track. The happyPathAttempt method does make sense.

[theangrydev]

See also: https://github.com/theangrydev/business-flows/wiki/9.0.0-Migration-Advice

[theangrydev]

The changes implemented in 9.0.0 and 9.1.0 overlooked something that I forgot about, which is that the sad type cannot be changed in the HappyPath.then method, which means that the NoSad type could never be changed.

There are a few possibilities:

• Write the "Try" (i.e. happy or technical failure) as a completely separate class hierarchy that ties into the usual BusinessFlow hierarchy when e.g. then is called. Problem here is there will be lots of very similar methods to the existing classes, but with the sad type omitted, which smells because I don't want to have to keep them in sync etc
• Go back to having to specify the sad type up front in HappyPath.happyAttempt. This also smells because you need to know up front what sad type you will be using later on in the flow
• Extend the BusinessFlow hierarchy and throw unsupported exceptions for methods that don't make sense for a "Try" and add on methods that do make sense. This smells even more :)

[theangrydev]

For now, I reverted the entire version 9 changes and released version 10 that picks up where 8.3.0 left off.