Why is does my step function stop executing instead of following the Catch #1 path?
Because you cannot catch States.Runtime errors. The docs state
States.Runtime
An execution failed due to some exception that it couldn't process. Often these are caused by errors at runtime, such as attempting to apply InputPath or OutputPath on a null JSON payload. A States.Runtime error isn't retriable, and will always cause the execution to fail. A retry or catch on States.ALL won't catch States.Runtime errors.
You tried accessing FaceDetails[0]... but there aren't any FaceDetails in your state.
Instead of catching this error you should put a Choice state after the DetectFace to determine whether you actually found a face and only then forward that face detection to the lambda. You can use a IsPresent check for $.FaceDetails[0]: https://stackoverflow.com/a/65693332/2442804 .
Related
I am trying to execute some statements within Try block. I am calling an API and performing some operations. There is one specific operation which is resulting in RuntimeError which is puked while running the program, although I am catching it with an exception. How do I go about avoiding the errors being puked from Try block?
try:
call API and perform some tasks.
encounters an error here
Except RunTimeError as ex:
print(ex)
Well as Susmit R. Veena said the point of try and except is to catch the error thrown in the try block.
In case you have some flow you want to ignore from its exceptions in the try block, than you can have a nested try catch block for the specific error you want to ignore and keep doing the logic after it is ignored.
for example:
try:
try:
call API and perform some tasks.
encounters an error here
Except TheErrorYouWantToIngore:
pass
keep on doing some stuff even TheErrorYouWantToIngore has been throwed
Except RunTimeError as ex:
print(ex)
the whole point of try and except is to catch the errors thrown by the code in try block in except block. Post the code for solution to the error
I use Pusher in my Rails-4 application.
The problem is that sometimes the connection is slow, so the execution of the code becomes slower.
I also get from time to time the following error:
Pusher::HTTPError: execution expired (HTTPClient::ConnectTimeoutError)
I send signals via Pusher with this code:
Pusher[channel].trigger!(event, msg)
I would like to execute it in background, so if an exception is thrown it will not break the flow of my app, and neither slow it down.
I tried to wrap the call with begin ... rescue but it didn't solve the exception problem. Of course even if it would, it wouldn't solve the slow-down problem i want to avoid.
Information on performing asynchronous triggers can be found here:
https://github.com/pusher/pusher-gem#asynchronous-requests
This also provides you within information on catching/handling errors.
Finally I implemented this solution:
Thread.new do
begin
Pusher[channel].trigger!(ch, ev, msg)
ActiveRecord::Base.connection.close
rescue Pusher::Error => e
Rails.logger.error "Pusher error: #{e.message}"
end
end
I have a unit test that creates an error condition. Normally, the class under test writes this error to the logs (using log4j in this case, but I don't think that matters). I can change the log level temporarily, using
Logger targetLogger = Logger.getLogger(ClassUnderTest.class);
Level oldLvl = targetLogger.getLevel();
targetLogger.setLevel(Level.FATAL);
theTestObject.doABadThing();
assertTrue(theTestObject.hadAnError());
targetLogger.setLevel(oldLvl);
but that also means that if an unrelated / unintended error occurs during testing, I won't see that information in the logs either.
Is there a best practice or common pattern I'm supposed to use here? I don't like prodding the log levels if I can help it, but I also don't like having a bunch of ERROR noise in the test output, which could scare future developers.
If your logging layer permits, it is a good practice to make an assertion on the error message. You can do it by implementing your own logger that just asserts on the message (without output), or by using a memory-buffer logger and then check on the contents of the log buffer.
Under no circumstances should the error message end up in the unit-test execution log. This will cause people to get used to errors in the log and mask other errors. In short, your options are:
Most preferred: Catch the message in the harness and assert on it.
Somewhat OK: Raise the level and ignore the message.
Not OK: Don't do anything and let the log message reach stderr/syslog.
The way I approach this assuming an XUnit style of unit testing (Junit,Pyunit, etc)
#Test(expected = MyException)
foo_1() throws Exception
{
theTestObject.doABadThing(); //MyException here
}
The issue with doing logging is that someone needs to go and actually parse the log file, this is time consuming and error prone. However the test will pass above if MyException is generated and fail if it isn't. This in turn allows you to fail the build automatically instead of hoping the tester read the logs correctly.
I have been trying to use c++/cx StorageFile::ReadAsync() to read a file in a store-apps, but it always return an invalid params exception no matter what
// "file" are returned from FileOpenPicker
IRandomAccessStream^ reader = create_task(file->OpenAsync(FileAccessMode::Read)).get();
if (reader->CanRead)
{
BitmapImage^ b = ref new BitmapImage();
const int count = 1000000;
Streams::Buffer^ bb = ref new Streams::Buffer(count);
create_task(reader->ReadAsync(bb, 1, Streams::InputStreamOptions::None)).get();
}
I have turn on all the manifest capabilities and added "file open picker" + "file type association" for Declarations. Any ideas ? thanks!
ps: most solutions I found is for C#, but the code structure are similar...
If this code is executing on the UI thread (or in any other Single Threaded Apartment, or STA), then the calls to .get() will throw if the tasks have not yet completed, because the call to .get() would block the thread. You must not block the UI thread or any other STA, and when compiling with C++/CX support enabled, the libraries enforce this.
If you turn on first chance exception handling in the debugger (Debug -> Exceptions..., check the C++ Exceptions check box), you should see that the first exception to be thrown is an invalid_operation exception, from the following line in <ppltasks.h>:
// In order to prevent Windows Runtime STA threads from blocking the UI, calling
// task.wait() task.get() is illegal if task has not been completed.
if (!_IsCompleted() && !_IsCanceled())
{
throw invalid_operation("Illegal to wait on a task in a Windows Runtime STA");
}
The "invalid parameter" you are reporting is the fatal error that is caused when this exception reaches the ABI boundary: the debugger is notified that the application is about to terminate because this exception was unhandled.
You need to restructure your code to use continuations, using task::then, as described in the article Asynchronous Programming in C++ Using PPL
Just to make sure you understand the async pattern, what is happening in your code is that you call create_task and immediately after that task has started you are trying to get the result with .get(). Calls to .get() will throw immediately if the task is still running or the file could not be found. Therefore, the correct way of structuring this is using a .then on your file task, ensuring that you have the result of this task before starting the next one.
create_task(file->OpenAsync(FileAccessMode::Read)).then([](IRandomAccessStream^ reader)
{
//do stuff with the reader
});
At that point the reader is available so you can do whatever you want to, even start a new task.
Also, it is possible that the call to OpenAsync is failing cause the file is empty, I would add a try catch block to the previous task, the one that gets the file, just to make sure that's not the problem.
I had been trying hard to figure out why the exceptions thrown from StartElement event handler are not being caught by my application which makes use of expat parser( in C). The application just terminates saying that it cannot find catch blocks, though I have all the catch blocks in place. It is just that since exceptions are being thrown from my own event handlers, XML_Parse API of expat is unable to pass it on to my code where I have all the catch blocks. One of the stackoverflow user with name 'Michael Anderson" suggested to rebuild expat lib with necessary gcc flags to make expat lib handle exceptions. Can someone let me know what flags are those? Or Suggest a better way out to handle errors in event handlers like startelement, endelement etc.
I somehow want XML_Parse API to return 0 if I encounter any exception in my registered event handlers. Please help. Thanks in advance.
Here is the code:
try
{
if( ! XML_Parse(.....) )
{
throw exception;
}
}
catch(...)
{
}
In the working scenario, if XML_Parse encounters a malformed xml file, it promptly returns zero, and I get into if block and throw exception, and it is caught fine.
But in the problematic case, the exceptions are being thrown from the event handlers but my application dumps core, and core stack says that it cannot find catch and finally calling std::terminate and abort.
Now, how do I make XML_Parse to return zero when I want to throw user defined exception from event handlers?
As per expat.h, you should invoke XML_StopParser(parser, 0) when you encounter an error in your handler that warrants aborting the parse.
XML_Parse will then return XML_FALSE. At that point you can invoke your application-specific error handling