Bloc: [Discussion] How should people react to invalid events or invalid states in `mapEventToState`?

[wujek-srujek]

1. When mapEventToState is called, we normally check the type of the event by a series of if checks. What should we do when the event type is unknown? assert in the last else (i.e. if the else bloc is reached, we know that no if handled the event type), throw an exception (assert is a no-op in release mode) or maybe just log?
2. Similarly, certain events only make sense for a specific state of the BLoC. We can check if the state is correct and act accordingly, but what should we do if the state is not correct? Should we assert, throw or maybe log?

What is the recommended way of dealing with these issues? AFAIK, the tutorials pretty much ignore invalid event types and incorrect states, the mapEventToState method simply doesn't yield anything and returns (yes, they are non-production examples, no critique here). In this case nothing will happen and the app won't work as expected, but it may be difficult to find the issue.

[narcodico]

Hi @wujek-srujek 👋

1. Each bloc expects an event of certain type/base type, so you cannot add random events; you should be aware of the existing events and handle them accordingly, so there's really no unknown type to deal with. You as the developer are in change of declaring those events and adding them to the bloc, so it shouldn't be anything unexpected for you.

2. I'd say most of the time you just want to ignore when the state is not what you expect, simply because the logic you're running only makes sense when a certain state type is present. So far I've never ended up in a situation where I had to care about the states not involved in business logic in regards to the currently processing event.

The tutorials do ignore these scenarios for the aforementioned reasons.
As long as you're handling all your events properly your app will run smoothly. ✌

[wujek-srujek]

Hi @RollyPeres, regarding 1, yes, I know, the programmer, define the types, but imagine I used to have event types A, B and C, but now I only support A and B, and forgot to delete type C and some part of the app that sends an instance of C to the BLoC. Sure, my bad, but it may be difficult to find.

If I use dynamic as event type to support whatever events I like, this gets even more risky as now I can put whatever in the Bloc.add method. But I guess dynamic is an anti-pattern in this context and it's my bad ;d

BTW I have personally been ignoring invalid states just as you describe, makes the code easier to follow, but saw some code from a colleague of mine where he logs warnings in this case and it got me thinking. But I guess tests should catch cases like this.

[narcodico]

When you decide you don't need C anymore I'm sure you will delete the C class. That will automatically force you to clear up the code using C. I don't see any risks in this, unless you are deciding you don't need C anymore but at the same time you don't take any actions to eliminate C, which means you haven't implemented your chore/feature. Nobody stops you from having a default handing of incoming events and logging/throwing them, but I don't see any benefits in doing so, since it's your responsibility to handle all those events and when you don't need one just delete that class and whatever code that uses it.
I suggest you using something like freezed which will offer you exhaustive casing, so you won't forget to handle a certain event or state.

[wujek-srujek]

Thanks @RollyPeres for you input. I don't know anything about freezed (apart from the questionable grammar ;d), I'll definitely look into it.