converter_path raises NetworkXNoPath exception without specifying src and dest types about girder_worker

[cdeepakroy]

It would be helpful to print the source and target types when that exception is raised for easy debugging

[zachmullen]

Indeed. There is also an actual bug here that we should fix, which is that the exception that we propagate in this case is pretty unhelpful. We should catch it and raise one of our own that contains information about the spec that caused the breakage, most importantly the source and dest types and formats, and the id of the input or output.

[danlamanna]

It looks like there exists a type/format combination in your spec that isn't registered in the worker.

Looking at your type/formats I would guess it's because string/string should be string/text. Let me know if that doesn't fix it for you.

[danlamanna]

The functions that determine how to go from one format to another have no idea what piece of data they're dealing with, and I would prefer that if possible.

I initially implemented it a bit differently, which was to remove this try/except. In this case it would have just thrown an Exception stating No such validator string/string. Does this work for you?

[jeffbaumes]

I agree that No such validator string/string is the correct error in this case so we should do that (and add a test for it). We should also implement and test that two valid formats with no path produces No path from a/b to a/c instead of NetworkXNoPath.

[cdeepakroy]

No such validator string/string is a good start. But as zach said it would be nice to know the id of the input/output which is causing this error. If there is no way of knowing the ID in the converter_path then, maybe raise something like No such validator string/string there and catch it somewhere else where the ID can be obtained and raise another exception there and give the ID.

[zachmullen]

My suggestion would be to wrap this logic in a try/except block and then raise something containing the types & formats as well as the ID. Within this block we should change it to two different try/excepts, one for the source tuple and one for the dest tuple, and if we raise an exception from that it should include the information from the offending tuple. Does that make sense?

[cdeepakroy]

+1 for what zach suggests

[cdeepakroy]

Also, can we use 'string' instead of 'text' for non-json format of string?

All other simple types seem to be like that except this.