Capturing exceptions inside Kv

[depau]

Hello,
I suggested this in another issue, but I want to repropose it as I think it will be a lot useful. It happens sometimes that something inside the Kv raises an unwanted exception that you cannot avoid. The only alternative is creating some python function that contains a try-except and prevents the app from crashing, but this makes the kv language itself unuseful.

Will you do that? For example one could wrap from a few properties to an entire tree in a try-except; the builder checks, when an exception occurs, if there was a try-excepts and avoids it in that case, or reraises it if there wasn't any.

Want to back this issue? Post a bounty on it! We accept bounties via Bountysource.

[tito]

Capturing exception and try/catch is not part of the language, and i doubt it would be. Using python for that is actually the best solution for handling issues, or you can use the general to indicate if you want to let it pass or not (http://kivy.org/docs/api-kivy.base.html?highlight=exceptionhandler#kivy.base.ExceptionHandler). But the second solution will still break all the stack call.

If you have specific use cases, please share them. I'm playing a long time with kv from the start, and never got the feeling that this would be needed.

Kv is meant for describing the UI, control part should (most of the time) stay in python.

[depau]

Thank you for showing me the exceptionhandler, I didn't see it. However I think this could be automated through Kv, I will post some usage cases tomorrow, as it's late now.

[depau]

Here are my use cases:
http://paste.ubuntu.com/6285886/

A more explicit if statement similar to this could also be useful, even if it's implicitly allowed with "x if True else y".

[tito]

This language / feature is not appealing is the first read. My point is a such error should be done in python directly. If you have a mymodule.get_image(), then ensure the get_image() always return a valid image.

About using try/catch for conditionnal statement within the kv language itself is weird.

Conditionnal and looping are part of the wishes to the user, but no "good" way have been found yet.

Your approach is mixing kv / python / kv / python, and i'm sure it make the langage even more un-readable. But at least, we have another example to look at.

[depau]

The methods you call from the kv are not necessarily part of the application. I could use #import and import an external module that eventually raises an exception in one of its methods. Creating a method in the application just to catch the exceptions in that method and prevent the app from crashing is a bit silly, isn't it?
And about mixing python with kivy, you're already doing it, why don't you take it to an higher level? I find what I proposed really useful: it would make programming interface really faster. I mean, if you're making a theme (remember, I made a kv based theme engine for my app) you shouldn't be forced to write some python code if all you need is checking if you have to show a widget or another. It's silly. Same for the exceptions...

Probably loops are not really useful in kivy, but who knows, maybe someone could find them useful in future...

[nadrimajstor]

For what it's worth, I would write it as:

Image:
    source: mymodule.get_image()
    size: "64dp", "64dp"
    on_error: self.source = "atlas://data/images/defaulttheme/image-missing"

[matham]

That seems too vague, i.e. to what does the on_error apply? To the whole rule including instantiation of Image? Or just a few of the rules. And if it's for the whole rule then it's too limiting. Also, this would clash with a property names error.

I think we should close this issue as this is unlikely to happen, at least in the way it's currently proposed.

[dessant]

The use case snippet is a bit unfortunate, it seems to be referring to handling a not found image, which has nothing to do with this thread because a wrong file path produces a white texture, not an exception.

For the original proposal, i don't see a need for try except in kv either, normally, kv should never fail in that way, and if it does, the code should be fixed, not exceptions handled. Exceptions originating from python function calls can also be handled on the python side.