search

Wox-launcher / Wox

A cross-platform launcher that simply works
http://wox-launcher.github.io/Wox/
GNU General Public License v3.0
24.58k stars 2.37k forks source link

Allow commands return errors #18

Closed orzFly closed 1 year ago

orzFly commented 10 years ago

Some commands may be failed to execute, such as typos. I think we should allow user to re-run their last command if there was an error before.

BTW, command history is important, I think.

qianlifeng commented 10 years ago

You mean we should expose the friend failed info to users? For example, I'm now executing fy hello to do some translations. But for some reason, the fy execution was failed. And we catched this error. Now, we should return a wrapped Result Item that indicates query failed, press xxx to requery., instead of returning the empty result list. If I'm right, it's a good idea. And if you have interests, you can pull me requests about this idea or I can add you to Collaborators so that you can commit directly if you would like to attend this project. I will be glad if you do so.

About command history, I thought about it. You can see in CMD Commit, I have completed a simple command history function for it. I think if we will provide a common commands history funciton for every workflows. At least, there should be a switch for workflows to turn it off or not. For some plugins, they may don't need command history.

orzFly commented 10 years ago

In fact the error, can be divided into two kinds.

  1. Errors in the CMD workflow, is occurred after executing the command. I don't think we can predict whether the command will fails. I don't mean the exit code of the program, but the result of Process.Start. Maybe the file cannot be found. I think the failed command should be accessed easily next time we use that workflow, especially in Win+R mode.
  2. Errors in the translation workflow, is something like the Instance Search in Google. I do agree with your ideas. I think the wrapped ErrorResult should have the ability to be invoked (re-query). After invoke that the input box should not be closed but just update the result.

On Mon, Jan 27, 2014 at 7:09 PM, qianlifeng notifications@github.comwrote:

You mean we should expose the friend failed info to users? For example, I'm now executing fy hello to do some translations. But for some reason, the fy execution was failed. And we catched this error. Now, we should return a wrapped Result Item that indicates query failed, press xxx to requery., instead of returning the empty result list. If I'm right, it's a good idea. And if you have interests, you can pull me requests about this idea or I can add you to Collaborators so that you can commit directly if you would like to attend this project. I will be glad if you do so.

About command history, I thought about it. You can see in CMD Commithttps://github.com/qianlifeng/WinAlfred/blob/master/WinAlfred.Plugin.System/CMD.cs, I have completed a simple command history function for it. I think if we will provide a common commands history funciton for every workflows. At least, there should be a switch for workflows to turn it off or not. For some plugins, they may don't need command history.

— Reply to this email directly or view it on GitHubhttps://github.com/qianlifeng/WinAlfred/issues/18#issuecomment-33358751 .

lances101 commented 8 years ago

Regarding what @orzFly said:

I think if a command fails, that specific plugin should handle the error and push the corresponding Result to Wox, because each plugin has a very specific functionality and it is not possible to make Wox handle everything. Maybe it is a command that should not be repeated or a different command should be invoked or whatever. The variety of needed actions for each specific case can be endless.

In other words, the plugins should handle the internal plugin errors during execution, not Wox. (unless it's an uncatched exception).

Correct me if i'm understanding something wrong.

orzFly commented 8 years ago

@lances101 I agree with you.

However this issue I posted years ago in fact pointed to reporting the failure to Wox so the next time when user opens Wox the input box will be filled with last command. For example:

  1. User opens Wox
  2. Invokes ">caalc"
  3. CMD Plugin handles the command but there isn't a program called caalc (should be calc)
  4. CMD Plugin handles the error by showing a dialog "Caalc is not a command or blah blah blah"
  5. (Wox hides)
  6. User opens Wox again 7 ">caalc" is preserved in the textbox