ChannelInfo: if getName() fails, try to check if there is a user readable error message

[Redirion]

• I carefully read the contribution guidelines and agree to them.
• I did test the API against NewPipe.
• I agree to ASAP create a PULL request for NewPipe for making in compatible when I changed the api.

This fixes #228

But in NewPipe we should also add a handling that will show the proper Youtube Error Message. At least it won't crash anymore if getName fails.

P.S.: don't judge me for committing on Christmas please. I have slow internet and thought I could do something useful while waiting.

[TobiGr]

That's not good and will fail in a NullPointerExcepetion. The frontend assumes, that when a ChannelInfo is returned there is information which can be processed. We need to fail here because we cannot get any information.
Just throw the ParsingException when obtainErrorMessage() brings no result. When obtainErrorMessage() returned an error message, I suggest to throw a ContentNotAvailableException with the message and then adjust the frontend handlers to display it. Can you check how long the other messages are, which are passed to other ContentNotAvailableException's? If they are too long or not helpful, we might need to add a new displayMessage attribute.

[Redirion]

That's not good and will fail in a NullPointerException. The frontend assumes, that when a ChannelInfo is returned there is information which can be processed.

but this is inline with the other cases. For instance

try {
           info.setOriginalUrl(extractor.getOriginalUrl());
       } catch (Exception e) {
           info.addError(e);
       }

would also render a NullPointerException if the originalUrl would be obtained without checking in frontend as there is no setting of an empty url in error case.

[Redirion]

I am now throwing the ContentNotAvailableException as requested. So I have renamed the PR as it now basically just gets a user readable error message.

[TobiGr]

I thought about extending the ContentNotAvailableException like this:

public class ContentNotAvailableException extends ParsingException {
    /**
     * Reason why content is not available.
     * Can be displayed to the user
     */
    private String reason;

   ....

    public ContentNotAvailableException(String message, String reason) {
        super(message);
        this.reason = reason;
    }

   public ContentNotAvailableException(String message, String reason, Throwable cause) {
        super(message, cause);
        this.reason = reason;
    }

    ....

    /**
     * {@link ContentNotAvailableException#reason}
     * @return null when no reason is available
     */
    public String getReason() {
        return reason;
    }

This allows us to display the reason in the app by checking if the reason is not null, otherwise display the generic "content unavailable" message.
We could also create an ContentNotAvailableErrorInfo Class which holds this information. @yausername @Stypox @Redirion What do you think?

[Redirion]

maybe instead of adding a new method (getReason) we could use an Java API method that should be fitting:
getLocalizedMessage (it actually is localized)

[Stypox]

I think @Redirion idea is good, since it follows the answer provided here: https://stackoverflow.com/questions/24988491/difference-between-e-getmessage-and-e-getlocalizedmessage
The issue is: what would getMessage() return? In theory it should return a non-localized reason, but obviously it can't, so is it OK for it to also return a localized message?

[Redirion]

If I understood @TobiGr correctly, he wants to have getMessage() return the none localized text "Could not get channel name" when getName() fails. Which was the state prior to this PR. With this PR getMessage() would return the localized error message from youtube that is now extracted with "obtainErrorMessage".

getLocalizedMessage just returns what getName returns if not overridden. So if we want to have both we could use getLocalizedMessage() (as an alternative to adding a new method like Tobi suggested)

[Stypox]

Oh that makes sense, then I agree with you, getLocalizedMessage is a good idea

[ShareASmile]

@TobiGr @Stypox this also needs to be implemented. Just a reminder.

[TobiGr]

@gillhash Thanks.
@Redirion We might need to update this after we solved #258

[Redirion]

#228 (comment)