Feature Request: Please give us error trapping

[Sabertooth]

Greetings!

Just my two cents but I hate so much that calling the itunesplugin dll when Itunes isn't running crashes the entire Rainmeter. i.e., pressing a play button for example. Skin level and/or meter level error trapping would allow the user to trap these errors and use them constructively, i.e., OnError [Action].

I'm totally open to any solution for this issue.
Sabertooth

[jsmorley]

The next beta actually fixes this issue with iTunes. Be out tomorrow.

[poiru]

The next beta actually fixes this issue with iTunes. Be out tomorrow.

This was actually fixed in r685, so it should be fixed in the latest beta.

Sabertooth, can you try downloading 1.4 beta r687?

[Sabertooth]

Greetings!

Itunesplugin.dll is a bad example perhaps since it's recent behavior was aberrant (I saw another thread about the Itunesplugin.dll problem). That doesn't change that error trapping could be very useful. For example, how are you determining whether Itunes is running or not? I haven't seen anyone who's incorporated such a check in their own config? Trapping the error would allow you to 'know' you need to run Itunes first and then deal with the issue. (i.e., OnError (execute! (iTunes.exe))

Sabertooth

[jsmorley]

You are confusing Rainmeter with a programming language. It's not. The underlying Rainmeter C++ code does trap errors to the best of our ability, but the skins are just files of "settings" in a sense. The kinds of errors that are going to crash Rainmeter, and they are rare indeed, are by their nature "fatal", and we can't just ignore them and "return control" (even saying that is to demonstrate a misunderstanding of what a skin is) to the skin after setting some kind of #ERROR# variable.

We try our best to trap non-fatal errors and gracefully just write a log entry and move on, or pop up a dialog like "MeterOne can't be bound with MeasureOne" or "Your skin has no meters" as a warning and either unload the skin or just disable the offending element.

It is true that external things like plugins or addons can cause a condition we don't anticipate and Rainmeter can crash, but while we can do our best to anticipate them or stomp them out when found, I don't think it would either be easy or practical to try and create a whole new approach where fatal errors are trapped, some kind of #ERROR# condition is set, and a new OnError bang is created to allow a user to take some action. It would be really huge and complicated. You would have to create a IfErrorValue= and IfErrorAction= mechanism, much like IfAboveValue= and IfAboveAction= and / or have individual measures/meters create "local" error conditions for it to not be useless.

Don't forget as well that in this example, and in many (probably almost all) other cases, the error is not happening in "Rainmeter". It's happening in the external plugin code, which adds another layer of complexity. The error trapping and condition setting would likely have to be done in the plugin and returned to Rainmeter (which would have to be specifically coded in each plugin / addon) and THEN Rainmeter would have to be coded to deal with it, detect that an error condition specific to a particular measure has occurred, evaluate some kind of IfErrorAction= statement on that measure, and execute whatever is after the "=". The better approach is to find bugs in plugins and addons and correct them. The iTunes plugin should know how to gracefully deal with the fact that iTunes is not running, and in fact now does.

I know that iTunes was just an example, but there is an easy way to do what you want. Just use the approach in this post, and if the executable in question is not loaded, just use !RainmeterDisableMeasure to avoid the problem, or run an !Execute statement to load the desired application.

http://rainmeter.net/forum/viewtopic.php?f=15&t=3907

[Sabertooth]

Greetings!

I know that iTunes was just an example, but there is an easy way to do what you want. Just use the approach in this post...

Thanks for the pointer to the example, it'll do the trick I expect.

You are confusing Rainmeter with a programming language.

No, I'm not. I'm looking for solutions to problems based on my experience which, admittedly, is influenced by my programming background. Not to mention that things like conditional branching are part of Rainmeter and are 'programmy' rather than 'settings', eh? However, I really appreciate the different approaches you provide to the problems I find . As I said Itunes was a bad example due to it's aberrant behavior, I wasn't talking about handling fatal errors per se. I knew that you were already trapping the errors, of course. I wasn't suggesting not too, your error trapping could just pass handling the error to the user or even just that an error condition had occurred and no more; i.e., write to the log *and* set the #Error# flag, no action necessary by the user....unless they wanted to do something.

You would have to create a IfErrorValue= and IfErrorAction= mechanism, much like IfAboveValue= and IfAboveAction= and / or have individual measures/meters create "local" error conditions for it to not be useless.

Wow, I actually like the sound of that! I guess it could get pretty complicated, agreed, but couldn't it be distilled to something really basic too?

I don't think it would either be easy or practical to try and create a whole new approach where fatal errors are trapped...

Errr, no offense, but whether an idea is easy or hard to implement in your framework shouldn't stop it from being suggested, it could still be a good idea and, while the difficulty may/must be considered by you, such consideration by myself isn't possible (I wouldn't have any idea about the difficulty or not). So, I hope you understand that my suggestions here will *not* take into consideration things I have no way of knowing.

Sabertooth

[jsmorley]

I wasn't suggesting that anyone (including me) has any idea how hard or easy it would be, and you are right, it is not a factor in the question, but only in the answer.

In any case, all things are possible, it's a computer... Just that my thinking is that this would be a large effort, with tons of "how/when" questions to be asked, and lots of code, and might be a solution looking for a problem most of the time. 99.9% of "errors" in a skin are not ones that have any programmatic impacts at all, but only cause the skin to behave in a perfectly valid but undesirable way.

Good exchange. Certainly worth thinking about some more...