@Ashrockzzz2003 if we are porting the application to a TUI then we can have a diagnostics box on the right hand side of the screen where things can be monitored constantly and error messages / success messages can be printed.

It can keep track of all events that are happening within the application and give visual updates to the user. (think of it as being similar to the chat section of a multiplayer gaming lobby - PLAYER JOINED, PLAYED LEFT, etc.)

@Ashrockzzz2003 @IAmRiteshKoushik ErrorF was used because I wanted the application to stop in case of Errors.

While we now actually are making use of those lines. It now raises a new problem.

The problem

Consider the case where the user did not use Amrita VPN and an error is thrown. What happens is:

Execute() -> start() -> getCoursesReq() -> fetchHTML()

In fetchHTML()

amrita_pyq/cmd/helpers.go

Line 16 in 0b8264e

fmt.Println("Error fetching the URL. Make sure you're connected to Amrita WiFi or VPN.")

This line prints the error first.
But we're also carrying the err string from fetchHTML back all the way to start() and printing it.

Now in the output: - TWO ERROR messages but in reverse order.

Error fetching the URL. Make sure you're connected to Amrita WiFi or VPN.
failed to fetch the HTML content

This doesn't look good to me. If we can give a cause and effect relationship to this and print properly, it will be useful. Else, we can just ignore this error message.

Or have a logger that separates debug and info level error messages to make better use of the logs.

What's your take on this @IAmRiteshKoushik and @Abhinav-ark?

I faced this issue when i tried to change Errorf to print.

@Ashrockzzz2003 @IAmRiteshKoushik ErrorF was used because I wanted the application to stop in case of Errors.

But return is already there to stop. But I'm sure Errorf did not stop execution, return did.
Let's try TUI
See how it goes.

@Ashrockzzz2003 if we are porting the application to a TUI then we can have a diagnostics box on the right hand side of the screen where things can be monitored constantly and error messages / success messages can be printed.

It can keep track of all events that are happening within the application and give visual updates to the user. (think of it as being similar to the chat section of a multiplayer gaming lobby - PLAYER JOINED, PLAYED LEFT, etc.)

let's try