more informative error for multi-gene graph

[matthewhirschey]

Problem: If a user enters custom genes (or a pathway?) that do not draw a graph, the error is uninformative. See pix below for same gene pair with two different filters.

Possible solution: Add a validate() in make_graph().

[matthewhirschey]

Here is the code as it currently stands, and it already has a validate() line to check if the gene is in the dataset (mostly for single gene cases, to prevent users from getting errors if they navigated to the graph page without entering a gene).

  output$graph <- renderForceNetwork({
    validate(
      need(data() %in% colnames(achilles), "No data found."))
    withProgress(message = 'Running fancy algorithms', detail = 'Hang tight for 10 seconds', value = 1, {
    make_graph(master_top_table, master_bottom_table, data(), threshold = rv$threshold, deg = rv$degree)
    })
  })

@johnbradley: do you have any suggestions for what we should check? (beyond whether the gene is in the data set). Seems like we might need to check for two possible outcomes (gene not in data set, OR filter criteria not returning a network)

[johnbradley]

I think what to check depends upon what can go wrong in make_graph. Perhaps you could add validate calls within make_graph to trap the various problems that occur with meaningful messages.

[matthewhirschey]

validate() is a shiny function, so not sure I'd put it in the make_graph function. I don't think wrapping if/else into the make_graph function would work, because the function returns a network, which then shiny renders. I'm not sure what'd happen if I returned text inside of renderForceNetwork({}). Unless I'm missing something, I think the key is in validate, so I'll look some more into how many validations I can string together with or |, etc.

[johnbradley]

I think you can just make multiple calls to validate one after another if joining them together with | starts to look confusing. Under the hood validate calls stop() so the function quits once the a call to validate fails.

[matthewhirschey]

Better solution. Addressed in e00af525

Will close after PR.

[matthewhirschey]

fixed with #97