Is there any documentation about exception handling? I have a specific case of needing to catch a system shutdown within a flow vs using the shutdown trigger, but I'd like to fully understand exception handling in general.
Thanks!
General Exception Handling
Moderator: Martin
Re: General Exception Handling
Which exception handling do you mean? The common one to catch the error is to add the exception connection : viewtopic.php?f=5&t=7314#p20955
From there you can put debug dialog as the exception branch, to know what is the error. Basically anytime an element create error, it will branch to the exception branch. Without the exception branch, flow will immediately stopped and produce error notif. With exception, flow still can continue to the exception branch and probably try other method until it finish normally.
From there you can put debug dialog as the exception branch, to know what is the error. Basically anytime an element create error, it will branch to the exception branch. Without the exception branch, flow will immediately stopped and produce error notif. With exception, flow still can continue to the exception branch and probably try other method until it finish normally.
Index of Automagic useful thread List of my other useful posts (and others')
Xiaomi Redmi Note 5 (whyred), AOSP Extended v6.7 build 20200310 Official, Android Pie 9.0, Rooted.
Xiaomi Redmi Note 5 (whyred), AOSP Extended v6.7 build 20200310 Official, Android Pie 9.0, Rooted.
Re: General Exception Handling
I would like to have one action that catches all exceptions without having to make an exception connection to it from every other element in the flow. The flow from that action onward would decide what to do based on what exactly the exception is.
The specific flow I'm working with might be interrupted by a shutdown event at any point and it would have to do certain things if that occurs. I'd rather not make a separate flow because there are several variables that contribute to the decision making and I don't want to make them all globals. Also, if the original flow continues while the shutdown flow is running, I might end up with inconsistencies.
The specific flow I'm working with might be interrupted by a shutdown event at any point and it would have to do certain things if that occurs. I'd rather not make a separate flow because there are several variables that contribute to the decision making and I don't want to make them all globals. Also, if the original flow continues while the shutdown flow is running, I might end up with inconsistencies.
Re: General Exception Handling
If I understood correctly, you say the shutdown would make an exception that stops the flow, but you want to continue from that and do other things before the device is fully off. I wanted to test that so I ran a looping flow and shut down my device while it was running, with Write to Log option on. I afterwards looked at the text file and saw no exception whatsoever, the flow just ended abruptly. So in order to achieve what you want, you need to have a separate flow with the Shutdown trigger. Something you can do to minimize the work of making all the variables global (if actually there are a lot of them), is to include into your flow the variable logger I saw from @Desmanto, that showed a simple way to dump all variables into a single global one in map form, so then you can go from that in the other flow and not have lots of global variables to handle: viewtopic.php?f=3&t=7285
Re: General Exception Handling
If the flow shuts down abruptly at shutdown, then that will have to do. I'll have a look at Desmanto's variable logger - that should help a lot.
Thanks!
Thanks!
Re: General Exception Handling
@piz : There seems to be no way to catch all exception from all elements. You have to connect it one by one. And not all element can be error. Such as Debug dialog doesn't branch to exception.
I agreed with ariloc to have separate flow to detect the shutdown. If you afraid of passing the local variable or overusing glovar, you can store all the variable needed to be passed to a glovar map. You can store it maybe as this.
You can have unlimited variables to be passed, but only using single glovar space. Later use glovar_passvar["folderpath"] to access variable {folder} from another flow.
To avoid inconsitencies, after the shutdown flow is triggered, immediately stop all the running flows.
I agreed with ariloc to have separate flow to detect the shutdown. If you afraid of passing the local variable or overusing glovar, you can store all the variable needed to be passed to a glovar map. You can store it maybe as this.
Code: Select all
global_passvar = newMapFromValues(
"folderpath", folder
"filename", filename
"images", image_path);
To avoid inconsitencies, after the shutdown flow is triggered, immediately stop all the running flows.
Index of Automagic useful thread List of my other useful posts (and others')
Xiaomi Redmi Note 5 (whyred), AOSP Extended v6.7 build 20200310 Official, Android Pie 9.0, Rooted.
Xiaomi Redmi Note 5 (whyred), AOSP Extended v6.7 build 20200310 Official, Android Pie 9.0, Rooted.
Re: General Exception Handling
Yes, that's the plan now. But you raise a question: you said "passing the local variable," what did you mean by that? I thought the only way to get info from one flow to another without the first flow executing the second directly is via glovars.
Thanks!
Thanks!
Re: General Exception Handling
Yes, Passing local variable via execute flow. I mean that if you use execute flow, every local variable from the caller flow will be brought to the executed flow, making it dirty with variables. You maybe don't want this to happen. Hence using Glovar map as the intermediary is better. The other way is to use Send Broadcast, pass the variable in extra. Then in the target flow, use trigger General Broadcast and get these extra. This doesn't use glovar, and doesn't pass every variable from the caller flow, it only pass the selected you mention in the Extras.
Index of Automagic useful thread List of my other useful posts (and others')
Xiaomi Redmi Note 5 (whyred), AOSP Extended v6.7 build 20200310 Official, Android Pie 9.0, Rooted.
Xiaomi Redmi Note 5 (whyred), AOSP Extended v6.7 build 20200310 Official, Android Pie 9.0, Rooted.