In implementing exception handling, it seems to follow the same pattern that any code which is invokable by the user (i.e. behind a button), needs try/catch/finally, and then has to propagate to the user (throw) and then show a message box to the user.
Is there ever any time when an exception can occur due to an action invoked by the user, but does not require letting the user know?
Thanks
Sure. One common example: a window is opened which is supposed to monitor the progress of some long-running task (whose execution is independent of the window) and the window is subsequently closed and Disposed. Just as the window is being disposed, the thread whose progress is being monitored attempts to use a BeginInvoke to update its progress indicator. The BeginInvoke will end up throwing an InvalidOperationException as a direct consequence of the user having decided to close the window at the precise moment he did, but there's no need to bother the user about it. Simply swallow the exception and move on.
Related
I have enabled the "Report not supported items" internal action so that I can receive notifications when an item becomes unsupported.
The problem I am having is that occasionally an item will become unsupported momentarily (because of connectivity issues for example), but 30 seconds later will become supported. This results in many redundant problem and the ok alert emails.
I know how to make alerts based on triggers less sensitive, but how do I do that with internal items? Note that I am comfortable with the fact that the item becomes unsupported momentarily.
You might wish to configure escalations in such a way that the email is not sent immediately, but on a second step, for instance. This way, only if the item is still unsupported when the second escalation step is executed, will the email be sent.
Please see https://www.zabbix.com/wiki/doku.php?id=howto/config/alerts/delaying_notifications for more information.
In the past few weeks I've been really into what happens "behind the scenes" in softwares, and there is something that really interests me - how does an event in Event-Driven Programming know when to occur?
Let me explain: Let's say we have a button in a GUI, how does the button know when it was pressed? Is there a loop that runs constantly and once it detects the button press it activates the event or is there a more efficient method?
In the case of a button, and how it knows it was clicked, I can only speak from experience with Windows programming, though I'm pretty sure it can be extrapolated to cover other types of operating systems and windowing systems.
Windows, the operating system, will keep tabs on your input devices, such as your mouse. When it detects, or probably more appropriately, is told that you clicked on one of the mouse button, it records a lot of information and then goes searching for what to do with that information.
I am guessing here, but it probably gets told through an interrupt, something that pings the CPU and tells it something special just happened.
With the information the operating system record, such as which mouse, which button, and where the mouse pointer was at the time, is used to determine what happens with that information.
Specifically, Windows tries to find out which program, window, and component in that window should be told about the mouse click. When it has found out where the mouse click went, it puts a message into the message queue of the thread that owns that window.
A message queue is like a loop that runs constantly, but it will stop whenever nothing is happening, ie. when no messages are put into its queue. So the message that was created because you clicked your mouse is being put into the message queue of that thread, and the message queue gets that message and processes it.
A message queue loop looks somewhat like this:
Message msg;
while (GetNextMessage(out msg))
{
ProcessMessage(msg);
}
Processing it here means that the thread figures out which internal component of the window the message should go to, and then calls a method on that component, giving it the message.
So basically your mouse click ends up being a normal method call on the button object.
That's all there is to it.
In .NET the method in question is named WndProc.
Now, what do we have event driven programming. What's the alternative?
Well, one thing you could do was create a new button class every time you need a new button in a window, embedding the code that should happen when you clicked the button inside that class.
This would get tiresome really quick, you would do the same thing over and over again, every time you need a new button.
In truth, the only thing that differs is what happens when you click the button.
So instead of creating a new button every time you need a new one in your program, let's make one button class that can do everything.
Except, how can that one class do everything? It can't, which is why, when the button is clicked, it needs some way of informing the owning program / window that it was clicked, so that whatever is specific to this button can be done.
And that's why events was created. You can create a generic button type that will signal to the outside world (outside of the button type) that specific things, "events" happen, and not care one bit about what actually happens.
Basically the way it works is that when you click the mouse button it generates a hardware interrupt that halts the currently executing thread and causes the OS to run a specific piece of code for handling that type of interrupt. In Windows this causes a message to be generated which is added to the event queue in a running application. At this point the thread that was interrupted to handle the hardware interrupt is resumed (or possibly some other thread). A GUI application essentially is constantly looping and checking for messages in this queue and when it gets one it will process it by doing something like check the x and y position of the mouse click to see if that is within the bounds of a button and if it is it will call some user specified code (the click event handler for that button). All of this is usually abstracted away to the point where you just supply the code that should be called when the button is clicked.
There are two different models that may present themselves here:
1/ The library takes control of the "event loop" - intercepting user events, OS events, etc., and relies on a (user-defined) callback mechanism to deal with specific events: (keyboard, mouse, etc.)
2/ The user must manage the event loop: check for events, dispatch based on the event, and (typically) return to event loop.
It would be helpful if you could provide more specifics.
When using distributed and scalable architecture, eventual consistency is often a requirement.
Graphically, how to deal with this eventual consistency?
Users are used to click save, and see the result instantaneously... with eventual consistency it's not possible.
How to deal with the GUI for such scenarios?
Please note the question applies both for desktop applications and web applications.
PS: I'm working with the Microsoft platform, but I imagine the question applies to any technology...
A Task Based UI fits this model great. You create and execute tasks from the UI. You can also have something like a task status monitor to show the user when a task has executed.
Another option is to use some kind of pooling from the client. You send the command, and pool from the client until the command completed and the new data is available. You will have a delay in some cases from when the user presses save to when he will see the new record, but in most cases it should be almost synchronous.
Another (good?) option is to assume/design commands that don't fail. This is not trivial but you can have a cache on the client and add the data from the command to that cache and display it to the user even before the command has been executed. If the command fails for some unexpected situation, well then just design a good "we are sorry" message for misleading the user for a few seconds.
You can also combine the methods above.
Usually eventual consistency is more of a business/domain problem, and you should have your domain experts handle it.
I think that other answers mix together CQRS in general and eventual consistency in particular. Task-based UI is very suitable for CQRS but it does not resolve the issue with eventually consistent read model.
First, I would like to challenge your statement:
Users are used to click save, and see the result instantaneously... with eventual consistency it's not possible.
What do you by this? Why is it not possible to see the result immediately? I think the issue here is your definition of result.
The result of any action is that that action has been performed. There are numerous of ways to show this! It depends on what kind of action do you want to complete. Examples:
Send an email: if user has entered a correct email address, it is almost guaranteed that the action will complete successfully. To prevent unexpected failures one might use durable queues since this kind of actions do not need to be done synchronously. So you just say "email sent". Typically you see this kind of response when you ask to reset your password.
Update some information in a user profile: after you have validated the new data on the client, most probably the command will succeed too since the only thing that could happen is the database error (if you use database). Again, even this can be mitigated by using durable queues. In this case you just show the updated field in the same form. The good practice for SPA is to have a comprehensive data store on the client side, like Redux does. In this case you can safely update the server by sending a command and also updating the client-side store, which will result in UI to shows the latest data. Disclaimer: some answers refer to this technique as "tricking the user", but I disagree with this definition.
If you have commands that are prone to error, you can use techniques that are already described in other answers like Websockets or Server-side events to communicate errors back. This requires quite a lot of additional work. You can also send a command and wait for reply or execute commands synchronously. Some would say "this is not CQRS" but this would be just another dogma to be challenged. Ensuring the command has completed the execution in combination with the previous point (client-side data store) will be a good solution.
I am not sure if there is any 100% bullet proof technique that allows you to always show non-stale data from the read model. I think it goes against the principles of CQRS. Even with real-time events you will only get events that indicate that you write model has been updated. Still, your projections could have failed and reacting on this is a whole other story.
However, I would not concentrate that much on this issue. The fact is that well-tested projections and almost-guaranteed commands will work very well. For error handling in 90% of situations it is enough to have some manual or half-manual process to recover from those errors. For the last 10% you can combine generic "error" messages pushed from the server saying "sorry, your action XXX has failed to execute" and the top priority actions could have some creative process behind them but in reality those situations would be very very rare.
There are 2 ways:
To trick a user (just to show that things has happened then they
really hasn't happened yet)
Show that system is processing request
and use polling in background (not good) or just timer with value of
your SLA.
I prefer the 1st option.
As someone has already mentioned, task based UI's fit well for this, and what I would do is employ a technique that 'buys you time' for the command to propagate.
For example, imagine we are on a list screen, where the user can perform various actions, one of which being to add a new item to the list. After choosing to add an item you could display a "What would you like to do next?" which could have 'Add another item', 'Do this task', 'Do some other task', 'Go back to list'.
By the time they have clicked on an option, the data would have hopefully been refreshed.
Also, if you're using a task based UI, you can analyse the patterns of task execution and use these "what would you like to do next" screens to streamline the UI. Similar to amazon's "other people also bought these items".
As previously stated, it is fine to tell the user that the request (command) has been acknowledged (successfully issued). In case of some failure, the system should communicate this to the requester, by means of:
email;
SMS;
custom inbox (e.g. like the SO inbox);
whatever.
E.g., mail client / service:
I am sending a mail to a wrong address;
the mail service says: "email sent successfully :)";
after few minutes, I receive a mail from the service: "email could not be delivered".
I believe a great way to inform the user about a recent failure is to present him an error panel while he's navigating through the application. A user gesture might be required in order to dismiss that alert etc.
For example:
I wouldn't go with tricking the user or blocking him from committing some other actions. I would rather go for streaming data toward UI after they are being acknowledged by a read side. Let's consider these two cases:
Users saves data and expects result. Connection is established toward server. After they are being acknowledged by a read side, they are streamed toward UI and UI is being updated.
User saves data and refreshes web page. Upon reload, data are being fetched from data store and connection for streaming is established. If read side didn't update the data store in the meantime, there's still an opened stream and UI should be updated after data reaches the read side.
Why streaming from read side and not directly from write side? Simply, that would be a confirmation that read side has been reached.
From technical aspect, Server-Sent Events could be used.
Disadvantage:
Results will still not be reflected immediately by a read side. But at least, in most cases, user will be able to continue with his work without being blocked by a UI.
There are several ways to handle eventual consistency. All of them are really to occupy the time from the User's action until the backend refresh.
User Reads A given user can only read from the same database node that they write to. Other users read from the replicated nodes. PROS: UI is quick enough, and application stays in sync. CONS: Your service architecture has to track and route Users to specific database nodes.
Disable the UI until the action has completed, and refresh it. Java Server Faces has a classic example of this. One could create a modal with a loading spinner to cover the UI until the refresh was completed. PROS: UI stays in sync with application state. CONS: Most every action creates a blocked UI. Users get very frustrated by the restricted UI, and will complain of application slowness.
Confirmation Immediately thank the user for their submission. Then let them know later (email, SMS, in-app notification) whether or not the action was completed. PROS: It's fast up front. CONS: UI lags behind system until refresh. Even with a notice, the User may get confused that they don't see the updates. It also requires integration of various communication channels. Users won't see their changes right away. If the action fails, they may not know until it's too late.
Fake it Optimistically assume that the action will complete. Show the User the resulting UI (upvote, comment, credit card confirmation, etc) and allow them to continue as if it succeeded. If there were failures, immediately show them as contextual errors: alerts next to the undone upvotes, in-app alert on the post with the failed comment, email for the declined credit card. PROS: UI feels much faster. CONS: UI is temporarily out of sync with application state, and you must resolve that. One case: you might fake creation of content with temp IDs. But after content is created, then the temp IDs will be wrong until the refresh. Second case, you might need to store all state changes on the UI after the action until the refresh. Then you need some Resolver to apply all the local state changes since the action was issued. This is resolution is non-trivial.
Web Sockets Subscribe the UI to an event stream so that when the action is completed on the backend, it is pushed to the front end. Is it one-way or two-way streaming? PROS: UI feels fast, and it's in sync with the application state. CONS: Consistent browser support, need a backend source of streaming events, and socket server scalability.
I have created an object of StreamingSubscriptionConnection that has a lifetime of 30 minutes , which is the max, and reopens automatically as suggested in Auto Reconnect When Using StreamingSubscriptionConnection in EWS.
Till this point everything works fine. however, after the first auto reconnect, if I would like to close the connection to add a new subscription, exceptions start to raise when I open the connection again saying "there is another connection open against the subscription"
Does anyone have any idea about how this happen, and how to solve it
Funny that your question came in today when I am knee-deep in this exact same area in my app! My understanding of this, after some back and forth with the folks in Exchange support, is that you can only add new subscriptions (or remove ones you don't want any more) in the OnDisconnect event handler. I have tried steps similar to yours and get the same kind of errors if I do it outside the handler. As I need for my app to add new subscriptions relatively promptly, I am tending toward a shorter timeout on my streaming connection (e.g. 3 mins), which I realize will add overhead for the more frequent TCP session establishments. In the long run, I'm not sure how bad this is, as under the covers streaming notifications are just doing long polling, so if you're getting lots of notifications, I think you have lots of HTTP Req/Rsp sequences anyway.
In concept Streaming Notifications are great, but based on the doc so far. i.e. the various blogs and forums like this, and the almost useless MSDN references, I have this sinking feeling that I am off on a rather unpleasant adventure I was not expecting.
... Old question ...
I found this documantation ...
First unsubscribe, THAN close connection. It works, but it calls both event handlers. First ErrorHandler (Exception: subscription was unsubscribed?!?) and than DisconnectHandler. So one have to handle tweak handlers with "outside" logic to differ this event from regular error/disconnect event...
Very unintuitive ... I have the same negative feelings about whole EWS )-:
Okay, so I have this small procedural SVG editor in Clojure.
It has a code pane where the user creates code that generates a SVG document, and a preview pane. The preview pane is updated whenever the code changes.
Right now, on a text change event, the code gets recompiled on the UI thread (Ewwwww!) and the preview pane updated. The compilation step should instead happen asynchronously, and agents seem a good answer to that problem: ask an agent to recompile the code on an update, and pass the result to the image pane.
I have not yet used agents, and I do not know whether they work with an implicit queue, but I suspect so. In my case, I have zero interest in computing "intermediate" steps (think about fast keystrokes: if a keystroke happens before a recompilation has been started, I simply want to discard the recompilation) -- ie I want a send to overwrite any pending agent computation.
How do I make that happen? Any hints? Or even a code sample? Is my rambling even making sense?
Thanks!
You describe a problem that has more to deal with execution flow control rather than shared state management. Hence, you might want to leave STM apart for a moment and look into futures: they're still executed in a thread pool as agents, but instead of agents they can be stopped by calling future-cancel, and inspecting their status with future-cancelled?.
There are no strong guarantees that the thread the future is executing can be effectively stopped. Still, your code will be able to try to cancel the future, and move on to schedule the next recompilation.
agents to indeed work on a queue, so each function gets the state of the agent and produces the next state of the agent. Agents track an identity over time. this sounds like a little more than you need, atoms are a slightly better fit for your task and used in a very similar manner.