User is presented with **Arcane error** when path to app does not exist

[tjarratt]

If I attempt to push, say, a java app to Cloud Foundry and my jar doesn't exist, I get a pretty arcane error about the lstat system call, which isn't too helpful. Admittedly I do personally know about this and how one looks up files in Go, but I suspect a lot of people do not.

./gradlew clean
echo WHOOPS I ACCIDENTALLY ALL THE JARS
cf push MySpecialApp -p build/libs/my-service-0.1.1.jar
Updating app MySpecialApp in org My-Special-Org / space My-Special-Space as tjarratt...
OK

FAILED
Error processing app files: lstat /Users/pivotal/workspace/my-special-service/build/libs/my-special-service-0.1.1.jar: no such file or directory

Something nicer about the files not existing would be pretty helpful.

I would propose

./gradlew clean
echo WHOOPS I ACCIDENTALLY ALL THE JARS
cf push MySpecialApp -p build/libs/my-service-0.1.1.jar
Updating app MySpecialApp in org My-Special-Org / space My-Special-Space as tjarratt...
OK

FAILED
Error processing app files: my-special-service-0.1.1.jar ***does not exist***

[cf-gitbot]

We have created an issue in Pivotal Tracker to manage this:

https://www.pivotaltracker.com/story/show/136226309

The labels on this github issue will be updated when the story is started.

[dkoper]

Hi @tjarratt

The advantage of the current implementation is that we print the platform specific error (I get "Error processing app files: GetFileAttributesEx d:\sdf.war: The system cannot find the file specified." on Windows), covering all platforms and various cases (other IO errors, file permissions, etc.).
Especially in obscure cases that we haven't expected/catered for, the user may interpret the message better (incl. having the option of searching it on the Internet).

I don't see how your proposed message is significantly better:
You dropped the path from the file (which I prefer to keep in as with e.g. cf push myapp -p $PROD/myapp.war it would show the actual path searched), replaced "no such file or directory" with "does not exist" (I think the former is common enough), so the only arcane/advanced term we have is "lstat" ("GetFileAttributesEx" on Windows).

I agree in this particular case the UX would be better without the term, but not convinced the effort to treat this case special is worth it.

I do appreciate very much you raising it, we (in the CLI team) have to be aware of such UX issues and balance the pros and cons as we develop the CLI.

Cheers,
Dies Koper
CF CLI PM

[tjarratt]

Both lstat and GetFileAttributes are both absurd messages to display to a user. These errors are generated deep in the implementation of the cli and cannot possibly serve any user very well. The fact that these errors get propagated from the recesses of the codebase up to the UI is sloppy and embarrassing to me as a Labs pivot. It's hard to show that output to a client developer and still believe that the CF CLI is a really truly beautiful piece of software (and I do want to think that a great part of it is beautiful). I think the underlying issue, that I could have certainly demonstrated better, is that not enough care has been taken to ensure users see consistent, meaningful errors when something unexpected happens. When I was on the CLI team we were still learning Go and grappling with its errors handling. We knew errors occurred and needed to be handled all the time, because the type system enforces this. What we didn't have was any particular product direction ensuring that users see good, meaningful messages in exceptional cases. Instead of "lstat" or "GetFileAttributes" a user should be shown an actionable message that helps them understand what went wrong, why, and what they can do to fix it. This is what I would like to advocate for. (Thank you for taking time to read these ravings of a mad man). Sent From A Very Small Keyboard

…

On Dec 15, 2016, at 18:40, Dies Koper ***@***.***> wrote: Hi @tjarratt The advantage of the current implementation is that we print the platform specific error (I get "Error processing app files: GetFileAttributesEx d:\sdf.war: The system cannot find the file specified." on Windows), covering all platforms and various cases (other IO errors, file permissions, etc.). Especially in obscure cases that we haven't expected/catered for, the user may interpret the message better (incl. having the option of searching it on the Internet). I don't see how your proposed message is significantly better: You dropped the path from the file (which I prefer to keep in as with e.g. cf push myapp -p $PROD/myapp.war it would show the actual path searched), replaced "no such file or directory" with "does not exist" (I think the former is common enough), so the only arcane/advanced term we have is "lstat" ("GetFileAttributesEx" on Windows). I agree in this particular case the UX would be better without the term, but not convinced the effort to treat this case special is worth it. I do appreciate very much you raising it, we (in the CLI team) have to be aware of such UX issues and balance the pros and cons as we develop the CLI. Cheers, Dies Koper CF CLI PM — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub, or mute the thread.

[dkoper]

I love listening to ravings from CLI users - mad men as well as women - imagine the opposite of hearing nothing at all!

I agree those words in those messages are not appropriate for end-users. I may not have accepted this if they were introduced during my tenure as PM.
But they are there now, as are many other, more embarrassing issues, and as much as I'd like to address each of them our resources are limited.

Closing as a wont-fix for now as we'll not likely get to it in a reasonable timeframe.