I'm working on a mobile flex application and I was wondering if there is a possibility to get the result of the trace function inside the application and not in the console to display it while running and without PC.
The trace command is usable only in debug mode and it display the text/value only in console...
trace(...parameters):void
Displays expressions, or writes to log files, while debugging. A single trace statement can support multiple arguments. If any argument in a trace statement includes a data type other than a String, the trace function invokes the associated toString() method for that data type. For example, if the argument is a Boolean value the trace function invokes Boolean.toString() and displays the return value.
If you need a different log system you can implement one...
ie.
You can create a class called Logger that takes a parameter and print to a label or directly to a file...
Related
I have used many discord API wrappers, but as an experienced python developer, unfortunately I somehow still do not understand how a command gets called!
#client.command()
async demo(ctx):
channel = ctx.channel
await channel.send(f'Demonstration')
Above a command has been created (function) and it is placed after its decorator #client.command()
To my understanding, the decorator is in a way, a "check" performed before running the function (demo) but I do not understand how the discord.py library seemingly "calls" the demo function.....?? Is there some form of short/long polling system in the local imported discord.py library which polls the discord API and receives a list of jobs/messages and checks these against the functions the user has created?
I would love to know how this works as I dont understand what "calls" the functions that the user makes, and this would allow me to make my own wrapper for another similar social media platform! Many thanks in advance.
I am trying to work out how functions created by the user are seemingly "called" by the discord.py library. I have worked with the discord.py wrapper and other API wrappers before.
(See source code attached at the bottom of the answer)
The #bot.command() decorator adds a command to the internal lists/mappings of commands stored in the Bot instance.
Whenever a message is received, this runs through Bot.process_commands. It can then look through every command stored to check if the message starts with one of them (prefix is checked beforehand). If it finds a match, then it can invoke it (the underlying callback is stored in the Command instance).
If you've ever overridden an on_message event and your commands stopped working, then this is why: that method is no longer being called, so it no longer tries to look through your commands to find a match.
This uses a dictionary to make it far more efficient - instead of having to iterate over every single command & alias available, it only has to check if the first letters of the message match anything at all.
The commands.Command() decorator used in Cogs works slightly different. This turns your function into a Command instance, and when adding a cog (using Bot.add_cog()) the library checks every attribute to see if any of them are Command instances.
References to source code
GroupMixin.command() (called when you use #client.command()): https://github.com/Rapptz/discord.py/blob/24bdb44d54686448a336ea6d72b1bf8600ef7220/discord/ext/commands/core.py#L1493
As you can see, it calls add_command() internally to add it to the list of commands.
Adding commands (GroupMixin.add_command()): https://github.com/Rapptz/discord.py/blob/24bdb44d54686448a336ea6d72b1bf8600ef7220/discord/ext/commands/core.py#L1315
Bot.process_commands(): https://github.com/Rapptz/discord.py/blob/master/discord/ext/commands/bot.py#L1360
You'll have to follow the chain - most of the processing actually happens in get_context which tries to create a Context instance out of the message: https://github.com/Rapptz/discord.py/blob/24bdb44d54686448a336ea6d72b1bf8600ef7220/discord/ext/commands/bot.py#L1231
commands.Command(): https://github.com/Rapptz/discord.py/blob/master/discord/ext/commands/core.py#L1745
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.
I have a production mobile Flex app that uses RemoteObject calls for all data access, and it's working well, except for a new remote call I just added that only fails when running with a release build. The same call works fine when running on the device (iPhone) using debug build. When running with a release build, the result handler is never called (nor is the fault handler called). Viewing the BlazeDS logs in debug mode, the call is received and send back with data. I've narrowed it down to what seems to be a data size issue.
I have targeted one specific data call that returns in the String value a string length of 44kb, which fails (release build). When I do not populate the String value (in server side Java code) on the object (just set it empty string), the result handler is called, and the object is returned, again, using the release build. This works in a debug build.
The custom object being returned in the call is a very a simple object, with getters/setters for simple types boolean, int, String, and one org.23c.dom.Document type. This same object type is used on other other RemoteObject calls (different data) and works fine (release and debug builds). I originally was returning as a Document, but, just to make sure this wasn't the problem, changed the value to be returned to a String, just to rule out XML/Dom issues in serialization.
I don't understand 1) why the release build vs. debug build behavior is different for a RemoteObject call, 2) why the calls work in debug build when sending over a somewhat large (but, not unreasonable) amount of data in a String object, but not in release build.
I have't tried to find out exactly where the failure point in size is, but, not sure that's even relevant, since 44kb isn't an unreasonable size to expect.
By turning on the Debug mode in BlazeDS, I can see the object and it's attributes being serialized and everything looks good there. The calls are received and processed appropriately in BlazeDS for both debug and release build testing.
Anyone have an idea on other things to try to debug/resolve this?
Platform testing is BlazeDS 4, Flashbuilder 4.7, Websphere 8 server, iPhone (iOS 7.1.2). Tried using multiple Flex SDK's 4.12 to the latest 4.13, with no change in behavior.
Thanks!
After a week's worth of debugging, I found the issue.
The Java type returned from the call was defined as ArrayList. Changing it to List resolved the problem.
I'm not sure why ArrayList isn't a valid return type, I've been looking at the Adobe docs, and still can't see why this isn't valid. And, why it works in Debug mode and not in Release build is even stranger. Maybe someone can shed some light on the logic here to me.
I have an SSIS package which has got a foreach loop. inside the foreach loop I have a script task. I have put breakpoint in that script task, which gets hit but the problem is, it only gets hit on the first iteration. so if F10 or F5 it does not break again on the second iteration.
how can i make it break each time on the same point on each iteration.
It seems to be a expected behaviour of SSIS, as stated in Books Online:
"If a Script task is part of a Foreach Loop or For Loop container, the debugger ignores breakpoints in the Script task after the first iteration of the loop."
http://technet.microsoft.com/en-us/library/ms137625.aspx
You can try to work around it with the following alternatives:
Interrupt execution and display a modal message by using the MessageBox.Show method in the System.Windows.Forms namespace. (Remove this code after you complete the debugging process.)
Raise events for informational messages, warnings, and errors. The FireInformation, FireWarning, and FireError methods display the event description in the Visual Studio Output window. However, the FireProgress method, the Console.Write method, and Console.WriteLine method do not display any information in the Output window. Messages from the FireProgress event appear on the Progress tab of SSIS Designer. For more information, see Raising Events in the Script Component.
Log events or user-defined messages to enabled logging providers. For more information, see Logging in the Script Component.
http://technet.microsoft.com/en-us/library/ms136033.aspx
I know this is old question, but I have an idea like to share
As it's been answered by Guilherme, I can add something might be useful, if your foreach is based on a SQL query, you can add a ROW_NNUMBER() to it and assign it to a variable, inside the script task you can compare the value of this variable and break the task on any row you want.
if (Dts.Variables["Your_Variable"].Value.ToString() == "4") {
Console.WriteLine("Break");
}
At least you can stop iterating any place in the loop, rather than the first iteration.
I have a CakePHP 1.2 application that makes a number of AJAX calls using the AjaxHelper object. The AjaxHelper makes a call to a controller function which then returns some data back to the page.
I would like to log the SQL queries that are executed by the AJAX controller functions. Normally, I would just turn the debug level to 2 in config/core.php, however, this breaks my AJAX functionality because it causes the output SQL queries to be appended to the output that is returned to the client side.
To get around this issue, I would like to be able to log any SQL queries performed to a log file. Any suggestions?
I found a nice way of adding this logging functionality at this link:
http://cakephp.1045679.n5.nabble.com/Log-SQL-queries-td1281970.html
Basically, in your cake/libs/model/datasources/dbo/ directory, you can make a subclass of the dbo that you're using. For example, if you're using the dbo_mysql.php database driver, then you can make a new class file called dbo_mysql_with_log.php. The file would contain some code along the lines of the following:
App::import('Core', array('Model', 'datasource', 'dbosource', 'dbomysql'));
class DboMysqlWithLog extends DboMysql {
function _execute($sql) {
$this->log($sql);
return parent::_execute($sql);
}
}
In a nutshell, this class modifies (i.e. overrides) the _execute function of the superclass to log the SQL query before doing whatever logic it normally does.
You can modify your app/config/database.php configuration file to use the new driver that you just created.
This is a fantastic way to debug things like this, https://github.com/cakephp/debug_kit