[FEA] Graph Input checking and cugraph's errors

[afender]

Currently, a corrupted graph input can result in a random error in the analytics algorithm later on. A feature to check the input graph should be added. This function should check as many graph properties as possible without traversing the graph (which would be too costly).
This function should be called before running an analytics function and return a clear error if some graph properties are not supported.

[seunghwak]

We may follow cudf: rapidsai/cudf#1390

They are adding

gdf_error validate(const gdf_column& column)

and we may add

gdf_error validate(const gdf_graph& graph)

[jrhemstad]

Note that gdf_error validate(const gdf_column& column) is simply a stop-gap solution.

In the medium term, this will go away in favor of a cudf::column class that is guaranteed to be valid after construction, i.e., any error checking would happen within the constructor and an exception would be thrown if it's erroneous.

[afender]

We should also see this issue as an opportunity to :

1. Identify the generic error handling solution for rapids (in RAPIDS core?)
2. Go through cugraph code and make error handling consistent

Precise points where we should improve:

• There are limitation and redundancy in cugraph error handling currently (cpp/src/utilities/error_utils.h)
• we do not need to define our own error handling mechanism for RMM ( [FEA] RMM_TRY and RMM_TRY_CUDAERROR rmm#83)
• we brought cuML's error handling mechanism to cuGraph without considering consistency ([REVIEW] Fea ext weak cc #312)

[seunghwak]

In addition, cuGraph's nvgraph files have their own error handling mechanisms as well.

src/nvgraph/include/util.cuh defines CUDA_CALL and THRUST_SAFE_CALL
src/nvgraph/include/nvgraph_error.hxx defines NVGRAPH_CATCHES, CHECK_CUDA, CHECK_CURAND, CHECK_CUBLAS, CHECK_CUSPARSE, CHECK_CUSOLVER, ...
src/nvgraph/nvgraph.h defines NVG_CUDA_TRY and NVG_RMM_TRY

[afender]

Input check and documentation was improved in #333.
Remaining changes should be addressed as part of the long run refactoring.

[BradReesWork]

This is related to #537

[github-actions]

This issue has been marked stale due to no recent activity in the past 30d. Please close this issue if no further response or action is needed. Otherwise, please respond with a comment indicating any updates or changes to the original issue and/or confirm this issue still needs to be addressed. This issue will be marked rotten if there is no activity in the next 60d.