Concrete errors for library APIs

[musjj]

This library makes very frequent use of anyhow::Result, especially for its public APIs. This is usually considered bad practice because it makes error handling impossible.

Like for example, with TopicProducer::send it's impossible to tell why it fails. Maybe the topic didn't exist, maybe there was a connection issue, there's just no way to know because it returns an opaque error type.

There's already a concrete error enum here:

fluvio/crates/fluvio/src/error.rs

Lines 20 to 26 in 20f2631

	pub enum FluvioError {
	#[error(transparent)]
	Io(#[from] IoError),
	#[error("Topic not found: {0}")]
	TopicNotFound(String),
	#[error("Partition not found: {0}-{1}")]
	PartitionNotFound(String, PartitionId),

Is there a reason why it's not used more often throughout the library? Concrete errors would make our lives SO much easier!

[sehz]

You can use downcast to match for specific error like here:

match err.downcast_ref::<PackageNotFound>() {
                Some(PackageNotFound {
                    package,

We used have concrete error type. Fluvio has lots of moving parts building distributed system. Errors can come from any source (network, disk, etc). With concrete error type, you have to continuously remap underlying error which takes lots of efforts to maintain. So many fluvio errors are actually application error type.