ui: NoRemoteError might be swallowed in Repo.fetch()

[Suor]

Here
https://github.com/iterative/dvc/blob/156fc9d4e1b438a5b9766a343af090f8bd22385c/dvc/repo/fetch.py#L58-L60

NoRemoteError will be swallowed and its supposedly helpful message won't be shown.

BTW, we behave differently with CloneError and OutputNotFoundError lower - we both show error to user and schedule for future DownloadError raise.

Even if this one is fixed we should discuss how heterogeneous errors should be combined into one.

[Suor]

Another thing that we mixed two types of errors here:

• random ones, like network issues or a file absent in cache
• persistent ones like NoRemoteError, CloneError or OutputNotFoundError

I would say we should stop doing that and raise persistent errors immediately and only collect download errors.

[Suor]

Another issue with collecting errors is that makes debugging troublesome since original error and stacktrace are lost.

[efiop]

@Suor You might not have any remote at all, but have imported data. dvc pull should work successfully in that case.

[efiop]

@Suor

random ones, like network issues or a file absent in cache

Random error is not going to be caught by the try-except that we have. We are catching only NoRemoteError (which we ignore if we have imported data) and DownloadError (for which msg is printed anyways).

[efiop]

persistent ones like NoRemoteError, CloneError or OutputNotFoundError

These are printed throgh logger.exception that we have. Am I missing something?

[Suor]

NoRemoteError is not printed. And random errors are caught in RemoteBase.download().

[Suor]

So we swallow NoRemoteError intentionally, we should really comment about things like this.

Overall behavior still looks erratic - we raise NoRemoteError occasionally, but always gobble up CloneError and OutputNotFoundError with a message.

Let's rename random/persistent errors into:

• ones indicating that something with dvc repo or env is wrong
• ones indicating some temporary issues

I don't see much value in collecting and combining first ones, that might show inn some very rare circumstances several of those at once instead of requiring a user fixing them one by one. The downside are:

• these messages might be obscured, e.g. OutputNotFoundError (telling about typo in out path) will be scrolled away with pbars and other messages
• when message is shown something still happends instead of letting user fixing this
• code is more complicated - we need to catch and gobble up lots of Exception classes (this is illustrated by the fact that we forgot CheckoutError)

[dberenbaum]

The original issue is no longer relevant in the code, so closing. If there's still a broader discussion that's worthwhile, feel free to reopen or create a new issue.