I have encountered something that has basically left me scratching my head (BP 6.4):
Description:
I have a file with about 5000 cases. First thing the process does is to add these cases in the queue. But before it adds these cases to the queue, it cross references the case with a database to check if any of them are already closed. If their are cases in the file that are already closed (in my file there are 321 cases that are already closed), process does the following: it first adds all cases that are NOT closed in the queue and then adds all cases that are closed in the queue. Process then marks all cases that are already closed as exception in the queue
Issue:
I'm seeing bizarre behaviour at this stage: what happens is that when the process marks the closed cases (321 cases from my file) in the queue as exception, not all of them get marked as exception. I always get about 40 odd cases that don't get marked as exception. But if i check a few hours later, they are marked as exception. As I am stopping the process after cases are added and marked in the queue, none of these cases have been worked.. they just seem to take time before they get marked as exception
Has anyone seen this behaviour?
As answered in the comments:
once the 40 odd cases are marked as exception, date\time of exception is set to exactly the time when the initial cases were marked as exception (well i say exactly.. round about the same time) and not 2-3 hours later when these cases were marked as exception
Knowing this fact, it is likely that what you're observing is something purely cosmetic. Unless in your workflow you require this data to be up-to-date in real time, it is unlikely that this affects workflows' functionality in any material way.
While trying to investigate the issue (and navigating in Control Room), Bluprism threw the following exception:
Below is the actual exception detail (from detail section)
************** Exception Text **************
System.NullReferenceException: Object reference not set to an instance of an object.
at System.Windows.Forms.ListViewItem.set_Selected(Boolean value)
at AutomateUI.ctlWorkQueueList.SetSelectedQueue(Predicate`1 pred)
at AutomateUI.ctlWorkQueueList.set_SelectedId(Guid value)
at AutomateUI.ctlWorkQueueManagement.SelectQueue(QueueGroupMember q)
at AutomateUI.ctlControlRoom.ChangePanel(TreeNode node)
at AutomateUI.ctlControlRoom.HandleAfterSelect(Object sender, TreeViewEventArgs e)
at System.Windows.Forms.TreeView.OnAfterSelect(TreeViewEventArgs e)
at System.Windows.Forms.TreeView.TvnSelected(NMTREEVIEW* nmtv)
at System.Windows.Forms.TreeView.WmNotify(Message& m)
at System.Windows.Forms.TreeView.WndProc(Message& m)
at AutomateControls.Trees.FlickerFreeTreeView.WndProc(Message& m)
at System.Windows.Forms.Control.ControlNativeWindow.OnMessage(Message& m)
at System.Windows.Forms.Control.ControlNativeWindow.WndProc(Message& m)
at System.Windows.Forms.NativeWindow.Callback(IntPtr hWnd, Int32 msg, IntPtr wparam, IntPtr lparam)
It looks like ListViewItem threw a NullReferenceException. This could be an environment issue or connection issue causing this problem. I will contact support to investigate further
Saying that, as per esqew's comment, this is looks like a cosmetic issue rather than an actual bug
Related
I have a range of Azure Function apps all outputting messages to Azure Service Bus using the IAsyncCollector<Message>:
public async Task Run([ServiceBus(...)] IAsyncCollector<Message> messages)
{
...
await messages.AddAsync(msg);
}
I'm getting errors logged from time to time looking like this:
Microsoft.Azure.WebJobs.Host.FunctionInvocationException: Exception while executing function: Function
---> Microsoft.Azure.ServiceBus.ServiceBusTimeoutException: The operation did not complete within the allocated time 00:00:59.9999536 for object message.Reference: ..., 7/13/2020 2:46:24 PM
---> System.TimeoutException: The operation did not complete within the allocated time 00:00:59.9999536 for object message.
at Microsoft.Azure.Amqp.AsyncResult.End[TAsyncResult](IAsyncResult result)
at Microsoft.Azure.Amqp.SendingAmqpLink.EndSendMessage(IAsyncResult result)
at System.Threading.Tasks.TaskFactory`1.FromAsyncCoreLogic(IAsyncResult iar, Func`2 endFunction, Action`1 endAction, Task`1 promise, Boolean requiresSynchronization)
--- End of stack trace from previous location where exception was thrown ---
at Microsoft.Azure.ServiceBus.Core.MessageSender.OnSendAsync(IList`1 messageList)
--- End of inner exception stack trace ---
at Microsoft.Azure.ServiceBus.Core.MessageSender.OnSendAsync(IList`1 messageList)
at Microsoft.Azure.ServiceBus.RetryPolicy.RunOperation(Func`1 operation, TimeSpan operationTimeout)
at Microsoft.Azure.ServiceBus.RetryPolicy.RunOperation(Func`1 operation, TimeSpan operationTimeout)
at Microsoft.Azure.ServiceBus.Core.MessageSender.SendAsync(IList`1 messageList)
at Microsoft.Azure.WebJobs.ServiceBus.Bindings.MessageSenderExtensions.SendAndCreateEntityIfNotExists(MessageSender sender, Message message, Guid functionInstanceId, EntityType entityType, CancellationToken cancellationToken)
at My.Function.Run(String mySbMsg, IAsyncCollector`1 messages)
I'm having a bit of a hard time figuring out when in the pipeline this happens. But I have recently learned about the FlushAsync method:
await messages.AddAsync(msg);
await messages.FlushAsync();
My question is the following. Why would I ever NOT include a call to FlushAsync in my function? Getting the timeout exception in my own code will make it possible to retry, do better exception logging, and more. Any downsides of flushing manually like this within the function code?
Why would I ever NOT include a call to FlushAsync in my function? Getting the timeout exception in my own code will make it possible to retry, do better exception logging, and more.
I'm going to go a bit further here and say that after I earned some experience with Azure Functions, I now avoid IAsyncCollector<T> completely. Some implementations publish on AddAsync; other implementations may publish on both AddAsync and FlushAsync. I suspect the service bus implementation is actually publishing on AddAsync, in which case FlushAsync may be a noop.
The nice part about IAsyncCollector<T> is that it gives you a "write these things" abstraction; all you have to do is provide a connection string, and the rest is magic. The problem with IAsyncCollector<T> is that it gives you an abstraction, and thus you have much less control.
Under the hood, how many retries are being done? Are they using constant delays or exponentially increasing? What's the behavior if it never succeeds? Usually none of this critical information is documented.
What's especially annoying is when the AF team changes the semantics of the abstraction. E.g., for some of the output bindings (either CosmosDB or storage, I don't remember), the retry behavior changed from one release of the functions SDK to the next.
So, I've gravitated towards avoiding output bindings, especially IAsyncCollector<T>. I usually want to do tight but exponentially increasing de-correlated jittered retries with a cap of a minute or so, but aborted when there's only a minute left of Functions runtime, and then the recovery behavior changes to writing a message to an error queue (with retries). This is way more complex than an IAsyncCollector<T> could ever provide, but it isn't that hard to do with Polly calling the SDKs directly.
Any downsides of flushing manually like this within the function code?
No. By default, IAsyncCollector<T>.FlushAsync is called by the functions host after your function executes. So if you call it yourself, you're just calling it early. It should be safe to call multiple times.
There's nothing wrong with calling FlushAsync in your code. The current implementation of IAsyncCollector for the ServiceBus output binding is that your messages get batched until FlushAsync is called or the function returns. When trying to send a high volume of messages I stumbled on the same Timeout exception as you. The solution I found is to call FlushAsync every N messages, in my case N=100 was the best trade-off. Calling FlushAsync too often would trigger obvious performance penalties.
Now I make TCP server with asyncio.
I want added exception error handling in my code. (like below)
try:
data = await reader.read(SERVER_IO_BUFFER_SIZE)
except SomeError:
#error handle
So, I look asyncio official document.
but I can't find any of information about Errors that may occur.
(link: https://docs.python.org/3/library/asyncio-stream.html#asyncio.StreamReader.read)
How can I get infomation about Errors that may occur?
The exact errors that may occur will depend on the type of the stream behind the StreamReader. An implementation that talks to a socket will raise IOError, while an implementation that reads data from a database might raise some database-specific errors.
If you are dealing with the network, e.g. through asyncio.open_connection or asyncio.start_server, you can expect instances of IOError and its subclasses. In other words, use except IOError as e.
Also, if the coroutine is cancelled, you can get asyncio.CancelledError at any await. You probably don't want to handle that exception - just let it propagate, and be sure to use the appropriate finally clauses or with context managers to ensure cleanup. (This last part is a good idea regardless of CancelledError.)
We have 2 applications, the first one is VCL project, the other is a windows service.
In the VCL project we do:
try
except
on E: Exception do
// do something with E.Message
end
but in the windows service (which uses several threads) we use:
try
except
// do something with Exception(ExceptObject).Message
end
The information I got from my coworkers is that "We must use ExceptObject in threads and E: Exception in applications that use GUI". But I couldn't find anything regarding this.
I found an example here http://edn.embarcadero.com/article/10452 where it uses an instance variable to store the exception and it uses the ExceptObject, but gives no explanation why.
Is this ExceptObject even thread-safe (since it comes from the unit 'System')?
So what is the right way to handle exceptions in Delphi and why is there more than one way to do it?
There is no right way for exception handling. There is just one way. What might confuse you could be dealing with the exception object which is created, and which causes an exception to raise, but whose lifetime is the most important for you here.
In general, there's only two ways of dealing with those exception objects. Either you let them alive beyond the exception block scope and release them by yourself or let them free by the RTL when the exception block ends.
But to answer what I guess you've asked. Exception class isn't thread safe. And, your coworkers were wrong as no one is forced to use specific exception handling in threads. These rules are the same for all threads created by the process, no matter what. Just, those exception objects can be unstable within exception blocks:
1. Get the current exception object from the ExceptObject
The ExceptObject returns the current exception object. In practice, it may cause this; if you store such object reference into a variable inside an exception handler block and another exception will get raised within such block, that stored instance may become invalid. Which is quite unsafe.
But it doesn't mean you could not take a reference of such object and pass it to another thread by using some synchronization mechanisms (since it's not a thread safe class) and work with it there. You just need to take care that no other exception will be raised because that would invalidate the previously stored object so as you must take care of staying inside the exception handler from the caller's point of view and you must use a kind of thread synchronization mechanism.
So actually working with the exception object acquired from an on expression can be more stable than using ExceptObject. But the same rules applies here as well; you'd need to synchronize the object instance from the on expression with another thread (since it's not a thread safe class), but in such case, object acquired from the on expression won't get changed unlike the ExceptObject one can be within a certain exception block.
2. Retain exception object by using AcquireExceptionObject
The AcquireExceptionObject function allows you to keep the exception object alive even out of the exception block.
For an exception handling when speaking about thread synchronization, I'd suggest you using the AcquireExceptionObject function which makes the exception object free to consume, even after the exception block ends. For you that brings the only responsability, free such acquired object by calling the ReleaseExceptionObject procedure or raising the exception by this object again.
Victoria is absolutely correct.
Personally, I have a strong preference for this idiom:
try
...
except
// IO error
On E : EInOutError do
ShowMessage('IO error : '+E.Message);
// Division by zero
On E : EDivByZero do
ShowMessage('Div by zero error : '+E.Message);
// Catch other errors
else
ShowMessage('Unknown error');
end;
To elaborate:
Victoria said "There is no right way for exception handling. There is just one way." That's absolutely correct.
The advice you got about "use one syntax for threads, and the other for GUIs" is simply wrong. There is no "different syntax" for "threads" vs. "GUI". That's nonsense :(
I prefer using on : MyExceptionType in an exception block.
I also prefer to differentiate different exception types, whenever/wherever possible.
The example you cited, http://edn.embarcadero.com/article/10452, deals with how to avoid a possible access violation if you don't handle the exception within that particular thread. Saving the exception instance in a member variable helps mitigate this problem.
The following link might help clarify:
http://www.delphibasics.co.uk/Article.asp?Name=Exceptions
Is it safe to call Exit on try except?
Or should I call raise instead?
I tried both example below and at raise example, the trace went through Delphi's internal library code. While exit just exit the procedure and nothing more.
I read that it's better to preserve application stack or queue or something like that. Will calling exit will break that stack?
Example 1 (raise)
SDDatabase1.StartTransaction;
Try
SDQuery1.ApplyUpdates;
SDDatabase1.Commit;
SDQuery1.CommitUpdates;
Except
SDDatabase1.Rollback;
SDQuery1.RollbackUpdates;
raise;
End;
..............//other codes I don't want to execute
Example 2 (exit)
SDDatabase1.StartTransaction;
Try
SDQuery1.ApplyUpdates;
SDDatabase1.Commit;
SDQuery1.CommitUpdates;
Except
SDDatabase1.Rollback;
SDQuery1.RollbackUpdates;
MessageDlg('Save Failed because: '+E.Message, mtError, [mbOK], 0);
exit;
end;
..............//other codes I don't want to execute
It's rare that alternate options (A vs. B) can be objectively evaluated as one is "always better" than the other. This is why it's important to properly understand the differences and implications of each.
When examined in isolation of a single method both your examples skip the code after the end of the except block. However, one leaves in an exception-state and the other doesn't. This has implications not in the method you write, but in the callers (direct and indirect) of your method.
procedur Caller1;
begin
//...[A]
Caller2;
//...[B]
end;
procedure Caller2;
begin
//...[C]
CallDatabaseMethod; {Will raise; or Exit; based on example chosen}
//...[D]
end;
The key distinction between your 2 examples is:
Example 1 is able to report the failure state up the call-stack.
Example 2 hides this information because the exception handler swallows the exception.
Example 1 would also skip [B] and [D] code. However, Example 2 would execute [B] and [D] code. When you understand this difference, you are then empowered to decide whether [B] and [D] should be executed.
However, I suspect that more often than not, the fact that CallDatabaseMethod failed to do everything correctly suggests that [B] and [D] should not be called. E.g. Suppose the database method updates customer account data and [B] and [D] perform action related to sending the latest statement. You probably don't want to send a statement when the update failed!
That said, if your method can be considered as "successfully completed" in spite of the exception, then by all means swallowing the exception is perfectly acceptable. E.g. Suppose you have a method to "Add a Row" and its post condition is simply that the row must exist in the database. Then if your database return a PK violation, obviously the row does exist. In this case it makes perfect sense to swallow the exception.
You can of course tweak the implementation of example 2 so as to not hide the error.
If your method is written as a function that returns success or failure state as a result, then callers can use this to resolve the aforementioned problems. E.g.
function Caller1: Boolean;
begin
Result := Caller2;
{Caller can decide to skip/ignore/do something different}
if Result then ...
end;
function Caller2: Boolean;
begin
Result := CallDatabaseMethod;
{Caller can decide to skip/ignore/do something different}
if Result then ...
end;
function CallDatabaseMethod: Boolean;
begin
Result := True;
//...
try
//...
except
on E: ExceptionType do
begin
//...
Result := False;
end;
end;
//...
end;
This is the same way the Windows API works. It does have its pros and cons:
Use return codes means caller has to remember to check for errors. (A common source of WinAPI questions on this site involve programmers failing to check for error return by API functions.)
So it's clearly an advantage that the exception model cannot be "ignored" by callers - they will surface eventually, even if it involves crashing the application.
But conversely again there's the disadvantage that the code to ignore exceptions that have been forced upon you is messier.
It's also important to caution against getting into a situation where large amounts of code run inside except blocks1.
The other disadvantage of structure exception handling is that it does have a significant performance overhead, so ideally you don't want to raise and handle them too often.
I recommend that the best approach is to determine which kinds of errors can be considered "normal" and ensure this is processed using explicit error results rather than exceptions. Certainly instances of 1 above are prime candidates.
Finally David has already flagged concerns with your message dialog in example 2. So this comment is on the assumption that this code always runs in a user context.
I understand the urge to show the message immediately. You have context that is lost by the time the exception propagates to the application level handler. One option to consider is using Abort which simply raises an EAbort exception.
try
//...
except
on E: ExceptionType do
begin
MessageDlg(...);
Abort;
end;
end;
The default application exception should ignore this exception and not display a message. If you have your own handler, you should similarly check the exception class before displaying any message.
As a side note I'd like to consider a particular sentence in the question.
I read that it's better to preserve application stack or queue or something like that.
Obviously if you're not sure about what you read, it's difficult explain it to you. You might already have a clearer picture based on earlier parts of my answer.
However, it might be referring to a different problem with another approach to exception handling. Raising a new exception. (You avoid this problem with raise; because it re-raises the original exception in original context.) This is the sort of thing is done to provide "more meaningful error message - similar to your example 2.
try
except
raise EOtherError.Create('My Message');
end;
The problem with the above is that when this exception eventually propagates to the application handler you've lost the original class; original exception address; and the original message. This approach often results in a clearer error to the user: e.g. "Unable to open file filename" but hides information that might have been useful in troubleshooting. E.g. Was it a disk error, was file not file, was it access permission error.
So: an important thing to think about whenever handling errors (no matter what approach you use) is: will there be enough information to resolve an error should it occur?
Both are safe in principle, but it's impossible to recommend one or other approaches. It depends on your design intentions. You have to decide which is appropriate given the intended usage of the code.
If you handle the exception in this code, and leave the function with exit, then the execution returns to the calling function, and it has no inkling of whether or not the function succeeded or failed. This may be problematic.
If you re-raise the exception, execution will move to the next suitable exception handler up the call stack, passing through any finally blocks along the way.
So, behaviour will differ, and it's down to you to decide which you want.
It is a common beginner's mistake to attempt to handle exceptions further down the call stack than is ideal. For example, suppose you want your code to be used in both a GUI app and a non-visual app. Your use of MessageDlg would not be appropriate in a non-visual app.
In a GUI app it is common for most actions to be in response to user input, for instance a button press. Exceptions typically should result in the entire operation being aborted. In which case you should not attempt to handle exceptions at all. Let them pass to the application level exception handler.
Finally, your code treats all exceptions in the same way. This is often ill-advised. For instance, an access violation should surely be treated differently from a database error.
I'm currently trying to wrap my mind around the correct way to use exceptions in Haskell. How exceptions work is straight-forward enough; I'm trying to get a clear picture of the correct way to interpret them.
The basic position is that, in a well-designed application, exceptions shouldn't escape to the top-level. Any exception that does is clearly one which the designer did not anticipate - i.e., a program bug (e.g., divide by zero), rather than an unusual run-time occurrence (e.g., file not found).
To that end, I wrote a simple top-level exception handler that catches all exceptions and prints a message to stderr saying "this is a bug" (before rethrowing the exception to terminate the program).
However, suppose the user presses Ctrl+C. This causes an exception to be thrown. Clearly this is not any kind of program bug. However, failing to anticipate and react to a user abort such as this could be considered a bug. So perhaps the program should catch this and handle it appropriately, doing any necessary cleanup before exiting.
The thing is, though... The code that handles this is going to catch the exception, release any resources or whatever, and then rethrow the exception! So if the exception makes it to the top-level, that doesn't necessarily mean it was unhandled. It just means we wanted to exit quickly.
So, my question: Should exceptions be used for flow-control in this manner? Should every function that explicitly catches UserInterrupt use explicit flow-control constructs to exit manually rather than rethrow the exception? (But then how does the caller know to also exit?) Is it OK for UserInterrupt to reach the top-level? But in that case, is it OK for ThreadKilled too, by the same argument?
In short, should the interrupt handler make a special case for UserInterrupt (and possibly ThreadKilled)? What about a HeapOverflow or StackOverflow? Is that a bug? Or is that "circumstance beyond the program's control"?
Cleaning up in the presence of exceptions
However, failing to anticipate and react to a user abort such as this could be considered a bug. So perhaps the program should catch this and handle it appropriately, doing any necessary cleanup before exiting.
In some sense you are right — the programmer should anticipate exceptions. But not by catching them. Instead, you should use exception-safe functions, such as bracket.
For example:
import Control.Exception
data Resource
acquireResource :: IO Resource
releaseResource :: Resource -> IO ()
workWithResource = bracket acquireResource releaseResource $ \resource -> ...
This way the resources will be cleaned up regardless of whether the program will be aborted by Ctrl+C.
Should exceptions reach top level?
Now, I'd like to address another statement of yours:
The basic position is that, in a well-designed application, exceptions shouldn't escape to the top-level.
I would argue that, in a well-designed application, exceptions are a perfectly fine way to abort. If there are any problems with this, then you're doing something wrong (e.g. want to execute a cleanup action at the end of main — but that should be done in bracket!).
Here's what I often do in my programs:
Define a data type that represents any possible error — anything that might go wrong. Some of them often wrap other exceptions.
data ProgramError
= InputFileNotFound FilePath IOException
| ParseError FilePath String
| ...
Define how to print errors in a user-friendly way:
instance Show ProgramError where
show (InputFileNotFound path e) = printf "File '%s' could not be read: %s" path (show e)
...
Declare the type as an exception:
instance Exception ProgramError
Throw these exceptions in the program whenever I feel like it.
Should I catch exceptions?
Exceptions that you anticipate must be caught and wrapped (e.g. in InputFileNotFound) to give them more context. What about the exceptions that you don't anticipate?
I can see some value in printing "it's a bug" to the users, so that they report the problem back to you. If you do this, you should anticipate UserInterrupt — it's not a bug, as you say. How you should treat ThreadKilled depends on your application — literally, whether you anticipate it!
This, however, is orthogonal to the "good design" and depends more on what kind of users you're targeting, what you expect of them and what they expect of your program.
The response may range from just printing the exception to a dialog that says "we're very sorry, would you like to submit a report to the developers?".
Should exceptions be used for flow-control in this manner?
Yes. I highly recommend you read Breaking from a loop, which shows how Either and EitherT at their core at nothing more than abstractions for exiting from a code block early. Exceptions are just a special case of this behavior where you exit because of an error, but there is no reason why that should be the only case in which you exit prematurely.