Improve feedback when getting files by ID

[touwwouter]

We know the path to hssp and dssp files, so we should provide more user-friendly feedback instead of showing a RunTimeError

Traceback (most recent call last):
  File "/srv/www/xssp-rest/.virtualenvs/xssp-rest/local/lib/python2.7/site-packages/celery/app/trace.py", line 240, in trace_task
    R = retval = fun(*args, **kwargs)
  File "/srv/www/xssp-rest/xssp-rest/xssp_rest/factory.py", line 104, in __call__
    return TaskBase.__call__(self, *args, **kwargs)
  File "/srv/www/xssp-rest/.virtualenvs/xssp-rest/local/lib/python2.7/site-packages/celery/app/trace.py", line 437, in __protected_call__
    return self.run(*args, **kwargs)
  File "/srv/www/xssp-rest/xssp-rest/xssp_rest/tasks.py", line 189, in get_dssp_redo
    raise RuntimeError("File not found: '{}'".format(dssp_path))
RuntimeError: File not found: '/mnt/cmbi4/dssp_redo/1crn.dssp'

We should also provide links to WHY_NOT
FMT_WHY_NOT_SEARCH_URL = "http://www.cmbi.ru.nl/WHY_NOT2/search/pdbid/{}"

[jonblack]

@touwwouter
What should we display instead of the standard error page for this? Do you like the idea of a separate error page that informs the user and links to why_not? Did you have something else in mind?

[touwwouter]

If you mean an error page different from the one referenced above, i.e. a page that hides the traceback and path and instead simply tells the user the file does not exist and provides a link to WHY_NOT, I like the idea!

[touwwouter]

The question is whether similar error messages can occur also when files are retrieved otherwise. If that is not the case, this issue can be closed and solved in #63.

[jonblack]

This issue is a specific instance of the more general issue #63.

This can only happen when looking for hssp files and dssp files locally. We'd need a custom exception so we can catch it and redirect to the specialised error page.

[touwwouter]

It is not a specific instance of #63 yet, since we don't check if the file exist during form validation and do not display red text there. We can make it one, provided similar errors do not occur after submission.

[jonblack]

It doesn't matter where the validation occurs. My point was, #63 asks for a page to explain all errors, and this issue asks for a better error page for a specific error.

In any case, using the form validation for this would be too soon. What the user provides (an id) is actually correct, so it should validate fine. The problem is that the data behind that id (for example, a HSSP file) doesn't exist, and WHY_NOT knows (hopefully) why.

The fix is simple: replace the RuntimeError with a custom FileNotFound error, catch it in the view when process_request is called, and redirect to the custom error page with the WHY_NOT link.

[jonblack]

Does WHY_NOT have an API? That'd be much nicer than a link.

[touwwouter]

Ah, ok 'the error page' refers to the new error page (like the title says ;-)). Then, obviously, you are right. Obviously, using form validation for this is wrong. The fix you propose sounds good.

I don't think WHY_NOT has an API.

[jonblack]

What message should I give to the user when the file hasn't been found? Something like:

The HSSP file for the ID 1crn doesn't exist. Please refer to the entry for 1crn in the WHY_NOT database for the cause.

[jonblack]

We may be forced to use the validator anyway because celery tasks fail when an exception is raised, and because the initial return value is a job id for which the status can be retrieved. The page itself updates via javascript, so using a validator would in this case be a lot simpler.