It seems that in the ASP.NET WebDriver API, executing the following when there is no javascript alert present results in an exception:
browser.SwitchTo().Alert();
IE and FF both throw a WebDriverException, but Chrome throws an InvalidOperationException.
So far, this is the only code that seems to work:
try
{
var alert = browser.SwitchTo().Alert();
if (alert != null)
alert.Dismiss();
}
catch (WebDriverException)
{
// alert was not present in IE or FF
}
catch (InvalidOperationException)
{
// alert was not present in Chrome
}
Is there a way to check that an alert dialog is present, without having to catch an exception?
The actual answer here is no, you must always catch an exception. The logic behind the design of the API is that you should always be aware of what browser state you expect. If you expect an alert to appear, you should be able to use switchTo() to switch to it and handle it. If you expect an alert to appear, and use switchTo() and it is not present, that is an exceptional condition, and an exception is thrown. The normal (non-exceptional) case is to not expect an alert, and thus there is no corresponding method to look for an alert not being displayed. Incidentally, this is the same logic employed by findElement(). You can argue that the wrong logic is being employed by the API designers, but that is the way the current API is implemented.
Keeping in mind your excerpt :
Is there a way to check that an alert dialog is present, without
having to catch an exception?
This exception is likely being caused by the statement below, upon trying to perform a switch when there is no alert window present :
var alert = browser.SwitchTo().Alert();
I would suggest that you try:
Start by using the getWindowHandles api method and investigate the
presence/absence of the Alert i.e another window. You can either loop through or check
using a counter.
If the Alert window is present you can use its window handle and dismiss the same.
Else (i.e If the Alert window is not present ) skip the execution of the statement below
and thus avoid the exception.
var alert = browser.SwitchTo().Alert();
More info abt moving between windows and window handle provided here
Related
Here are 2 different ways I can listen to a stream. The top one gives no IDE warning about cancelling a subscription. The bottom one does.
// No IDE warning about cancelling subscription
_loginBloc.state.listen((state) {});
// "Cancel instances of dart.async.StreamSubscription"
StreamSubscription s = _loginBloc.state.listen((state) {});
If I use the first method, do I need to cancel the subscription somehow, or will it dispose of itself?
There is no behavior difference between these two. You are running in to a limitation of the lint. That lint has a number of false positives and negatives.
In general if you aren't using the StreamSubscription returned from listen you should be using forEach instead.
If you know that the Stream will end before whatever is listening doesn't care about it anymore there isn't any need to explicitly cancel. Where you want to be sure to cancel is if there is a point in time where the listener no longer cares about the result - say because it's a widget which is no longer being displayed.
I have setup a custom intent and it all seems to be working fine except that the handler is not being called. Siri responds as if everything was successful but I don't see anything in the console output and none of my breakpoints are triggering... Here is the handler...
#implementation IntentHandler
- (id)handlerForIntent:(INIntent *)intent
{
// This is the default implementation. If you want different objects to handle different intents,
// you can override this and return the handler you want for that particular intent.
NSLog(#"In handlerForIntent.");
if ([intent isKindOfClass:[TriggerSceneIntent class]])
{
return [SceneIntentsHandler sharedInstance];
}
return self;
}
#end
I have breakpoints at the if statement and both return statements. None of them are being hit. I also never see "In handlerForIntent" in the console log in xCode.
I'm guessing this is something fairly simple that I missed but I'm not seeing it. Welcome any suggestions?
I faced a same problem - handler wasn't called.
Finally I've found out, that although the project supports iOS 11.4, it initially set IntentExtension target to iOS 13. And my device, which I use for testing, has 12.4.
So my advice: check your deployment target for each target.
Is it possible to stop (kill) asynchronous Call?
In my app I have at client side sth like:
Meteor.call('doCalculation', function(err, result) {
//do sth with result
});
'doCalculation' may take long time (this is ok) I dont want user to start new call when he/she has already one running call, I want to allow user to stop current call and submit new one. How correctly do this?
The only idea I have is to communicate between client and server using mongo. In some place in 'doCalculation' function I can observe some mongo document/collection and based on this do sth in the function (e.g. call exception). Do you have any better ideas?
You can use a semaphore for this purpose. When the semaphore is 1, requests are allowed to be sent. When the semaphore is 0, requests are not allowed to be sent. The semaphore should be 1 by default and just before you send the request, you need to set it to 0. When a response is successful, you set the semaphore back to 1.
As about the timeout: You could use a time out using setTimeout after sending the request, like this:
if (semaphore) {
var isTimedOut = false;
var isSuccess = false;
semaphore = 0; //No need to use var keyword, as this should be declared outside of this scope
Meteor.call('doCalculation', function(err, result) {
isSuccess = true;
//do sth with result
});
setTimeout(function() {
if (!isSuccess) {
isTimeout = true;
//do something else, to handle the time out state
}
}, 10000);
}
This is tricky, because you cannot generally set timeouts from the client's point of view. You don't need to, for a bunch of architectural reasons. The most important thing is that if you lose network connectivity or the server crashes (two cases timeouts are designed to manage), the client is aware immediately because it is disconnected. You can use Meteor.status().connected if this happens often.
It sounds like you're running a long calculation on the server. My suggestion is to return a calculationId immediately, and then update a collection with progress, e.g., CalculationProgresses.update(calculationId, {$set: {progress: currentProgress}}) as you calculate. Your UI can then update the progress reactively, in the most convenient way possible.
Note, that when you do run long calculations on the server, you need to occasionally "yield," giving the chance for other work to happen. Node, on which Meteor is based, is tricky for long calculations if you don't master this notion of yielding. In Meteor, you can yield easily by updating a collection (e.g., your progress collection). This will solve lots of problems you're probably experiencing as you write your application.
i think you need a server-side solution for this. if you go with a client-side solution, you don't handle 2 cases:
the user reloads their browser
the user uses 2 browsers
i would create these methods:
isCalculationActive() -- this checks if the user already has a calculation active. on the server, you can either keep that fact in memory or write it to the db. on the client, if this returns false, then you can proceed to call doCalculation(). if true, you can give the user a popup or alert or something to ask if they want to cancel and proceed.
doCalculation() -- this cancels any outstanding calculation by that user and starts a new one.
with these implemented, the user can reload their browser w/o affecting either the running calculation or correct behavior. and if they try a 2nd browser, everything should still work as expected.
if you want to give the user the option to simply stop the job and not start a new one, then you can simply create:
cancelCalculation() -- this cancels any outstanding calculation by that user.
I have to add a control inside a changeCompany() in an existing class.
I suppose the code below is OK, but I have a doubt : Does the "return" order imply that a return to the original company is done ?
Or is there to add a statement, unknown by me, something like revertToPreviousCompany()?
try
{
changeCompany(companyId)
{
// the method will produce a message and return false if an error
if (!this.doSomeChecks()) {
return;
}
// much more code below
Yes that is OK as in some situations you wouldn't even be able to revert it if not done by the runtime itself.
Imagine a callstack in which you have try - catch around some code your are calling and you expect there may be thrown an error but if the code which calls your code already established a transaction your handler is not called and therefore you wouldn't have a chance to undo the changeCompany
I am seeing strange behaviour with the flash.media.Sound class in Flex 3.
var sound:Sound = new Sound();
try{
sound.load(new URLRequest("directory/file.mp3"))
} catch(e:IOError){
...
}
However this isn't helping. I'm getting a stream error, and it actually sees to be in the Sound constructor.
Error #2044: Unhandled IOErrorEvent:.
text=Error #2032: Stream Error. at... ]
I saw one example in the Flex docs where they add an event listener for IOErrorEvent, SURELY I don't have to do this, and can simply use try-catch? Can I set a null event listener?
IOError = target file cannot be found (or for some other reason cannot be read). Check your file's path.
Edit: I just realized this may not be your problem, you're just trying to catch the IO error? If so, you can do this:
var sound:Sound = new Sound();
sound.addEventListener(IOErrorEvent.IO_ERROR, ioErrorHandler);
sound.load(new URLRequest("directory/file.mp3"));
function ioErrorHandler(event:IOErrorEvent):void {
trace("IO error occurred");
}
You will need to add a listener since the URLRequest is not instantaneous. It will be very fast if you're loading from disk, but you will still need the Event-listener.
There's a good example of how to set this up (Complete with IOErrorEvent handling) in the livedocs.
try...catch only applies for errors that are thrown when that function is called. Any kind of method that involves loading stuff from the network, disk, etc will be asynchronous, that is it doesn't execute right when you call it, but instead it happens sometime shortly after you call it. In that case you DO need the addEventListener in order to catch any errors or events or to know when it's finished loading.