fix: emitting a state in a closed Cubit throws an error

[ra48ad]

Description
Trying to emit a state when the cubit is closed (can happen for example in async functions) leads to an Error being thrown. This behaviour may be intentional, but it is - however - different from a Bloc's behaviour the emit is called.

Steps To Reproduce

1. Create a new Cubit
2. Add an async function that waits for 5 seconds, then emits a new state.
3. Create a new instance of this Cubit in your main method and call the function in 2) and then close the Cubit.
4. You should get an Error thrown that says "Cannot emit new states after calling close"

Expected Behavior
Calling emit on a closed Cubit ignores the new state and throws no error (Just like a Bloc would)

Screenshots

Additional Context

[felangel]

Hi @ra48ad 👋
Thanks for opening an issue!

Are you able to share a link to a minimal reproduction sample illustrating the problem/inconsistency you're seeing? It'd be much easier to help if you could share a repro, thanks!

[ra48ad]

Hi @ra48ad 👋 Thanks for opening an issue!

Are you able to share a link to a minimal reproduction sample illustrating the problem/inconsistency you're seeing? It'd be much easier to help if you could share a repro, thanks!

Thank you for your reply!

Sure, here are two comparable samples for a Cubit and a Bloc:

Cubit

class CounterCubit extends Cubit<int> {
  CounterCubit() : super(0);

  // delay emit to simulate async operation
  void increment() => Future.delayed(
        Duration(seconds: 3),
        () => emit(state + 1),
      );
}

void main(List<String> args) {
  final cubit = CounterCubit();
  cubit.increment();
  cubit.close();
  // prints 0, exception [StateError] thrown (bloc_base.dart line 97)
  print(cubit.state);
}

Bloc

enum CounterEvent { increment }

class CounterBloc extends Bloc<CounterEvent, int> {
  CounterBloc() : super(0) {
    on<CounterEvent>(_onCounterEvent);
  }

  Future<void> _onCounterEvent(CounterEvent event, Emitter<int> emit) async {
    if (event == CounterEvent.increment) {
      // delay emit to simulate async operation
      return Future.delayed(
        Duration(seconds: 3),
        () => emit(state + 1),
      );
    }
  }
}

void main(List<String> args) {
  final bloc = CounterBloc();
  bloc.add(CounterEvent.increment);
  bloc.close();
  // prints 0, no exception thrown because of isClosed check (bloc.dart line 202)
  print(bloc.state);
}

As you can see, there is a (small) difference in behaviour of both, even though the code is very similar.
In a real world app, it could be sometimes easier to use a Cubit instead of a Bloc, but this behaviour leads to writing extra isClosed checks in the Cubit to prevent the exception.

What do you think? is there anyway to prevent the exception without adding extra checks in the Cubit?

[bambinoua]

Why does that throw StateError in bloc_base.dart line 97 needed? As for me the isClosed should be handled as in Bloc (bloc.dart line 202) and it is not interesting to know either stream closed or no. We basically know that if the bloc is initialized then its stream is active, if bloc is closed (due to widget dispose) then any new events should be just discarded and I don't want to see error.

For example, I have a case where I downlooad the image and get its size. It is a long operation which I can break. Now I get a StateError because of widget is already disposed but emit is still trying to send new state. To avoid this I need to add additional check on isClosed in my code. But actually, I repeat, I am not interesting when and why the bloc was closed. I know exactly that it will be closed on widget dispose.

[felangel]

This behavior was introduced to be consistent with how StreamController works in Dart. I'm open to adjusting the behavior and welcome all feedback from the community 👍

[ra48ad]

Thank you for your kind reply! @felangel

I understand this point of view and it makes sense. however, since I started using Cubits instead of Blocs in big parts of my apps, this behaviour have been a pain for me and my team. I am glad you are considering a change.

Would it be ok if I make a Pull Request with the change for you to review it?
My suggestion would be to simply return if the cubit is closed (in BlocBase), just like Bloc. What do you think?