Error handling

[RFSH]

Currently, we don't any sort of error handling in this project. We're making a lot of assumptions, and the code can easily break if any of those assumptions are not met.

In this issue, I will outline what would be the desired error handling method in OSD viewer. I will not mention any specific errors and will just outline all the possible/preferable ways that we could handle errors. As the next step, @rastogi-bhavya should list all the errors that OSD viewer might throw. Then we can be more specific about how we want to handle each of them. Or whether we need to implement all or parts of the error handling methods that are outlined here.

Error types

We can categorize errors into two general categories:

1. Internal: errors that can be solved/reported within the osd viewer and won't propagate to Chaise.
2. External: errors that have to be reported to Chaise.

In both categories, an error can either:

• cause the whole app to break. We should show a popup that disables/hides all the controls on the page, shows a proper message, and offer ways to resolve the error.
• disable a feature. In this case, we could show some sort of alert/warning to the users to inform them of the issue. Or we might want to fail silently and only report the issue in the console.

As I mentioned I'm not familiar with all features of the app, so I won't list the errors. We should create an errors.js file that will be the place that we define all these different types of errors. We should try to follow the same code style that is used in the repository, but for reference you can take a look at ermrestjs or Chaise examples.

(I'm not trying to dictate the implementation here, but the error prototype should define the external vs. internal, as well as warning vs. actual error. We might want to have a hierarchy of these prototypes.)

How to handle errors

If we want to mimic the same mechanism that is used in Chaise, we first need to define some sort of "global" error handler. Since Chaise is using Angular built-in features, we cannot have the exact same mechanism here. We can use the window.onerror. This will catch any uncatched Javascript error that is thrown from anywhere on the page.

By leveraging this, we can throw errors from different locations in the code, and then we can handle them in the common window.onerror function. The callback function can then decide how it should handle the error. Whether it's going to be blocking or just warning. Whether it should send a message to Chaise or just handle it in OSD.

Although, in some cases, we might want to handle an error locally without leaving it unhandled. We should review this when we have the list of errors, but I feel like for the warning messages it might be easier to call some predefined callback in our code to handle the warnings. The most important benefit of using window.onerror is the fact that you don't need to worry about "unhandled" errors. Errors that might be thrown because of some unforeseen code path. But if we're the ones that are manually throwing error, we can just call a predefined callback instead.

[RFSH]

Error handling is not completely done yet, for now, we're just logging the errors in the console without properly displaying them to the user. That's why I reponed this issue.