While I'm developing my MS Access application, I open it with shift click. When an Error occurs, that is not trapped (by ON ERROR ...), a message box pops up informing me about the error. This is a good thing.
When a user open my application, he does't shift click, and an appropriate Start Form opens. However, now untrapped Errors don't show up, the application behaves as if the user clicked the Stop Button on the message box. I don't want this behaviour.
Is there an option / property / variable that provides the same behaviour in the production code (preferably even when the application id converted to an mde) as in development, i.e. show a message box for every untrapped error? Or is it neccessary to trap errors in every single event routine and pop up a message box by program?
It turns out, this is a side effect of setting the AllowSpecialKeys property to False. This can be done programmatically, but I did it in the menu under Tools > StartUp.
Since this property allows the user to open the code editor, it kind of makes sense, but the relationship of the phenomen described to this option was puzzling for me.
Does this mean, that if I want to hide my code, I need to write all those error handlers? Or is there one central place (like a main method in Java) where I can invoke an error handler. Alternatively, could I allow specical keys and just protect the code with a keyword?
You can create your own error handler and add it to all procs, subs and functions. You have this very nice MZ Tools VBA add-on that allows you many thing such as adding line numbers to your code, "preprogramming" your error label, etc.
If you are smart enough, you'll be able to use this add-on to generate a standard "error management" code displaying things such as err.number, err.description, and the undocument erl value, which is the number of the line where the error occured (you must first have your lines numbered before being able to get this value).
EDIT: I just opened this question on a similar subject.
As alluded to, MZ-Tools 3.0 is a great tool to aid in quickly adding error handlers. Also remember that errors which occur in procedures without error handlers "bubble up" to the last-invoked On Error statement. (And if no statement exists you get the little gray debug box.) The net effect of this, is that you can do minimal error handling by simply adding error handlers only to those procedures which are Public (or Friend) or called by event. This will make sure you always have at least 1 "top level" error handler invoked. If you want to add special handling to your private procedures after that feel free. If not, when an error occurs in them they will "bubble up" to the top level error handler.
Related
I would like to have many devices testing a game, and I find the best way to debug a game and solve specific code problems is to have the device connected and in debug mode in Adobe ANIMATE, that way I can catch any Errors in the Output window.
For Example, if I am debugging and connected to Animate, the output window will throw errors like :
ReferenceError: Error #1065: Variable bg_storage is not defined.
at global/flash.utils::getDefinitionByName()
at Game/stageAdd()[/Users/**/Game.as:360]
Now I know exactly what the problem is and where to find it. I love errors like this.
My question :
If I didn't have a device connected to Animate in Debugging mode, is there a way to make the game detect any errors thrown and store them as a String, that way I can put up a big text block on the game of the error string and keep track.
or at least a way to log them some how?
Ex :
If an error is thrown, have that error text set as a String variable, then have a text box write out that String variable.
I hope that isn't too confusing. If I am going about debugging in a poor way, I would love to know what you guys do to keep track of errors without being connected to debug mode.
EDIT
I can see an approach is you to add an uncaughtErrorEvent event to each function to be able to catch these errors...
loadbar.uncaughtErrorEvents.addEventListener(UncaughtErrorEvent.UNCAUGHT_ERROR ... )
I am trying to make it so any error thrown in any part of the game will trace that error somewhere to a String value that I can call, so that I can see any error thrown during a play test session without being connected to debug mode.
Thanks!
Sure. There's a class intended exactly for that: https://help.adobe.com/en_US/FlashPlatform/reference/actionscript/3/flash/events/UncaughtErrorEvent.html See examples at the bottom of the page to listen to the right instances for that event.
You are also free go grab my own class that does the thing you want: https://bitbucket.org/thydmitry/ru.delimiter/src/2756fadd741a6d44276fde1701470daf24cebfa8/classes/ru/delimiter/utils/Log.as?at=default&fileviewer=file-view-default
You will need to add it to your project and then call in the main document class (in constructor, preferably):
Log.create(this);
Log.handleExceptions(this, true);
Is it possible to throw an exception in a Logic App?
Specifically, I'm trying to throw an exception inside of a scope. Then in the run after of the scope I'd check if it failed and inspect it for errors. I tried using a terminate inside of a scope, but that terminates the entire logic app run.
As an updated solution we can use Terminate control, Terminate control has 3 status: Failed, Canceled, and Succeeded.
Quick Answer (TL;DR)
Problem: MSFT Azure logic app throwing exceptions
Workaround: Use logic app Scope element to simulate throwing exceptions
Create a scope element to use as your "try-catch" block
Force the scope element to fail with an invalid command to simulate an exception
Allow the scope element to fail naturally and that will count as an exception too
Detailed Answer
Context
MSFT Azure logic app workflows
live version as of 2020-06-14
Problem
Scenario: Developer wishes to throw an exception or use try-catch semantics in a logic app
Solution
As of this writing, the live version of the product does not support this feature. There is a workaround.
Workaround
Use logic app scope element
add a conditional statement inside the scope element
If the conditional statement meets the failure condition, force an exception with a deliberately invalid command
for example create a variable assignment with the value int('__ERROR__')
If the conditional statement does not meet the failure condition, do nothing
The rest of the logic app consists of two paths
The first path runs on the success of the scope element
The second path runs on the failure of the scope element (failed, skipped, timed out)
Example
Create a scope element as a "try-catch" block
Create a variable compose element with an invalid command
int('__ERROR__') ## this will cause the enclosing scope to fail
## the string __ERROR__ cannot be cast to integer
Respond to exit status of the Scope element enclosing your exception
See also
related SO answer about forcing exceptions https://stackoverflow.com/a/61101945/42223
No, there is no Action or Connector directly analogous to something like a throw in C#.
The closest you can get right now would be to do something like use another LogicApp instead of a scope from which you can return a specific status code.
It seems like there still is no option for this inside Logic App or its little brother Power Automate / Microsoft Flow.
The way I have come up with and have used in some flows, is I simply add an action for something I know for a fact will fail.
The simplest (and probably the cheapest as the built-in actions cost less in Logic Apps, even if we are talking fractions of a dollar here either way) is probably to initialize a variable, e.g. called ThrowException with type of integer.
Then a "Set variable" action is added wherever I want my flow to fail, where I set the value (remember it is of type integer) to any string expression. I simply use the expression string('Exception').
Simple example screenshot
Since the value is set via an expression this is still a valid template, but will fail upon runtime when the value is actually being set.
After this, simply use parallel branches, with appropriate Run After settings, as usual.
Intro:
I have two separate forms.
frmABC
frmXYZ
I have frmABC in focus and I run a procedure that will "Tick" a checkbox called ChkConfirmed on frmXYZ.
Question:
What is the difference between these two ways of referencing another form?
1. Form_frmXYZ.ChkConfirmed = True
2. Forms!frmXYZ.ChkConfirmed = True
For some reason, only #2 works in this scenario. For me this is bewildering purely beacuse I have always used #1 and it has never complained before (when I say complain, I mean it does the job).
But, when I use #1 here and step through the code, it definitely runs the code but does not check any boxes...just nothing.
So, I would love to know the technical differences to help me understand when to use each one and in what cases.
EDIT:
Actual code snippet (as requested)
#1 Version
#2 Version
Access (I think >=97) treats Forms as a Class which means your forms are now a class module and can have all [class behaviors] including instancing.
Form_your_formname: you are referencing the Form via the Class module.
Forms!your_form name: You are referencing the form by its form name.
To access a form via Forms!form_name, the form must already have been loaded. Otherwise the form won't be reachable and you will get an error message "the referenced ...... not found"
On the other hand, Form_form_name can be accessed at any time as a class. It can have multiple instances like all classes do. Accessing an unopened form via its class module will cause the form is being instanced. This means Access will create a new hidden instance of that Form.
To test this try following.
Create a new form called: frm_test with a text box in it called: txt_id
go to your immediate window and try following code:
Edit forgot to mention. The test form hast to have a vba module attached to it then only it becomes a class module
Form_frm_test.txt_id = 1
Form_frm_test.visible = true
?Form_frm_test.hwnd
docmd.openform "frm_test"
?Forms!frm_test.hwnd
Now you will see two instance of the frm_test form and each of them will have their own window handle.
to answer your question:
But, when I use #1 here and step through the code, it definitely runs the code but does not check any boxes...just nothing.
its because your form is being instanced and its hidden.
So, I would love to know the technical differences to help me understand when to use each one and in what cases.
Technical explanation given above.
if your form is already loaded you can use the Form!form_name / form_name to access it. If you are instancing use the class name.
To be honest, I've never seen your 1st example used, ever... In fact a quick test in Access 2010 fails with an "Object Required" error message. All the code I've ever done uses the exclamation, which (someone correct me if I'm worng) works in all circumstances where you would need to reference another form for something.
I was reading the documentation for cfthrow and came accross this
When to use the cfthrow tag
Use the cfthrow tag when your application can identify and handle
application-specific errors. One typical use for the cfthrow tag is in
implementing custom data validation. The cfthrow tag is also useful
for throwing errors from a custom tag page to the calling page.
For example, on a form action page or custom tag used to set a
password, the application can determine whether the password entered
is a minimum length, or contains both letters and number, and throw an
error with a message that indicates the password rule that was broken.
The cfcatch block handles the error and tells the user how to correct
the problem.
Have I been doing it wrong all this time or is this just a terrible use-case?
I was taught that exceptions shouldn't be used to handle regular application flow but for stuff that is somewhat out of your control. For example, a file being locked when you go to write to it.
A user breaking a password rule doesn't quite sound like something that's out of your control.
That is a poor example not a poor use case. I personally would pass in the parameters to a validation function and return a result that contained a pass or fail and a collection of failure messages to display to the user.
How I use exceptions is as follows.
Within functions. Let's say that you have a function that you are getting some data from the database and you are then constructing a structure from it. If the query returned has no values you have several options:-
You could return an empty structure and let the calling code deduce the problem from the fact the structure is empty. This is not ideal because then the application has to have complicated logic to address the missing data.
You could return a more complex datatype where one property is whether the process went ok and the actual data. Again this is not optimal as you have to then make this access the property on every call when the majority of the time you have data and again your application is dealing with this issue.
Or you could raise a custom exception with cfthrow indicating that there is no record that matches. This then means that you can choose to ignore the prospect of this error happening and let it bubble up to the onError handler or you could surround it in a try catch statement and deal with it there and then. This keeps your API clean and sensible.
Wrapping external errors let's say that you connect to an external API using cfhttp over https. Now this requires installing the certificate in your keystore otherwise it throws an error. If this certificate gets updated then it will start erroring again. In this instance I would wrap the call in a try catch and should this be the error I would wrap that in my own custom exception with a message detailing that we need to update the cert in the keystore so that any developer debugging it knows what to do to fix it without having to work it out. If it is not that particular error then I would cfrethrow it so that it bubbles up and is dealt with by whatever exception handling logic is above the call.
These are just a few examples, but there are more. To summarise I would say that throwing exceptions is a way of communicating up through the tiers of an application when something has occurred that is not the hoped for behaviour while keeping your API/Application logic clean and understandable.
It's really up to your discretion. It's extremely common in many languages to use exceptions for everything, including input validation.
Importantly, exceptions have nothing to do with something being in your control or not. For example, suppose that you have a fairly long and complicated module that uploads a file. There are many fail points in something like that: the file could be too big, the file could be the wrong format, etc. Without exceptions your only option is a lot of if/then checks and some kind of status return at the very end. With exceptions, all you have to do is use a set of cfthrows:
<cfthrow type="FileUpload.TooBig" message="The file size was #FileSize#, but the maximum size allowed is #MaxFileSize#">
<cfthrow type="FileUpload.WrongType" message="The file type was #FilType#, but the accepted types are #AcceptedTypeList#">
Then, whatever is calling the file upload function can catch either with <cfcatch type="FileUpload"> or catch a specific one (e.g. <cfcatch type="FileUpload.WrongType">).
Also, technically a user breaking a password is out of your control, in the sense that the user has determined the value for the password. That said, I loathe password rules as invariably they make it harder, not easier, to maintain security.
I was wondering how to make it so the rest of the program runs when one component fails to (and therefor the rest of the path that relied on this component is incapacitated as well). In other languages, this is equivalent to "catching an exception," but the added issue here is that I'm afraid that even if such a feature existed (cant find if it does), then the rest of the program would still try to run... Any advice would be very much appreciated. Thanks in advance!
LabVIEW doesn't have exception handling, but handles error in a different way: (nearly) all VIs accept an error cluster as input (and so should yours); if it is positive (an error occurred), the VI will return immediately, passing error as output, and next will get it as input, etc. This is called error.
As all these VIs transmit this cluster between each others you will get it in your top-level VI, so if error occurs you just have to cleanup stuff correctly it and exit.