feat(bloc)!: add support for strongly typed errors on `Emitter.onEach`/`Emitter.forEach` about bloc

[felangel]

Hey @narcodico 👋
Thanks for opening an issue!

It seems a bit risky to do this because if I'm understanding correctly, this change could result in runtime type exceptions since bloc would be casting the object to type E for you.

What would be the benefit of that as opposed to:

await emit.onEach(
  _repository.watchData(),
  onData: (data) => add(DataChanged(data)),
  onError: (failure, stackTrace) => add(DataFailed(failure as MyFailure, stackTrace)),
);

The other issue is onError might be called with errors that are outside of the scope of _repository.watchData() for example, if the underlying stream isn't a broadcast stream and there are multiple subscriptions, onError would be called with a StateError.

As a result, I don't think it's safe to do this because the underlying subscription mechanism operates on Object so I don't think we can always safely make the type more specific without risking runtime TypeErrors.

Let me know what you think and thanks again for taking the time to file this issue! 🙏

[narcodico]

Hey @felangel 👋

What would be the benefit of that as opposed to:

await emit.onEach(
  _repository.watchData(),
  onData: (data) => add(DataChanged(data)),
  onError: (failure, stackTrace) => add(DataFailed(failure as MyFailure, stackTrace)),
);

The benefit would be that it would save the developer from manually having to do the cast. It's if the current onEach would not accept a generic data type, but rather would give you a dynamic back and then you'd have to do:
onData: (data) => add(DataChanged(data as MyData)). It's not as clean as having a generic type.

The other issue is onError might be called with errors that are outside of the scope of _repository.watchData() for example, if the underlying stream isn't a broadcast stream and there are multiple subscriptions, onError would be called with a StateError.

I completely agree with this, but at the same time, a developer opting out of the default Object for a custom type would do that because the errors on the stream were handled and converted into a custom failure, e.g.:

Stream<MyData> watchData() => _dataSource.stream.handleError(
        (Object error, StackTrace stackTrace) =>
            throw MyFailure.from(error, stackTrace),
      );

but is also aware of how the stream is being used.
I also feel that the StateError you mentioned about non-broadcast streams being listen to multiple times should not be gracefully handled, since it's an error, not an exception, and should be fixed before releasing.
I can't think of a different error besides this, that could potentially happen after listening to a stream were you handle errors like the one above. Can you?

As a result, I don't think it's safe to do this because the underlying subscription mechanism operates on Object so I don't think we can always safely make the type more specific without risking runtime TypeErrors.

This feature would be great for developers that want to take full control over error handling. I think the usage it's pretty much in the hands of the developer. And the great thing is that not specifying a custom error type would continue operating on Object.