I am learning how to use Maybe observable. I created the below example. Incase of
Maybe.just(value) I will receive the value in onSuccess callback.
In case of Maybe.just(null), I expected to receive the log from onError. However, according to the posted code, when I run the code, the App crashes and I do not receive any logs.
Would you please tell me why I am not receiving any logs from onError()?
code
Maybe.just(null)
.subscribe(
i->Log.i("TAG:", "[onSuccess]: " + i),
err->Log.e("TAG", "[ERROR] err.getMessage(): " + err.getMessage()),
() -> Log.i("TAG", "[COMPLETED]: ")
);
You can't create a Maybe doing Maybe.just(null). It will throw a NullPointerException, that's why your app crashes.
Some people suggested that the library should have the option to Create a Maybe from null in RxJava, but unfortunately that won't happen:
Closing as won't happen. Static methods returning RxJava types can live on any external class.
A workaround for doing that, is to replace this:
Maybe.just(null)
For this:
Maybe.fromCallable(() -> null)
Related
I have an async ngxs action that throwsError().
I would like the default error handling mechanism to ignore this thrown error because I will be handling it in my code via ofActionErrored(). However, for other actions, default error handling should still take place.
Right now, both the ofActionErrored() and default error handling (via Angular/Ionic) tries to deal with the error.
The alternative I can think of is to dispatch Xxx_SUCCESS and Xxx_ERROR actions from within the initially dispatched action, something I would like to avoid if i can help it.
Advice appreciated.
There is a feature request that raised a similar concern at the NGXS repo. We've discussed in the core team meeting and we'll focus that for the next release. You can provide your feedback there: https://github.com/ngxs/store/issues/1691
You can use ofActionCompleted which as a result can provide the error, if there is one. An example taken from the code I am working on:
this.actions$.pipe(
ofActionCompleted(GetMe)
).subscribe((data) => {
const errorStatus = data.result.error['status'];
if (!data.result.successful && errorStatus === 403) {
this.snackbar.openFromComponent(TranslateSnakeBarComponent, {
data: {message: 'USER_DISABLED'}
});
}
});
I'm actually on swift 2.3.
Inbound Call works great with CallKit. But OutGoing Call ....
I saw the SpeakerBox project, I do the same things.
But it doesn't work.
To start my call, I used
let handle = CXHandle(type: .PhoneNumber, value: "TOTO")
let startCallAction = CXStartCallAction(callUUID: uuid, handle: handle)
startCallAction.video = video
let transaction = CXTransaction()
transaction.addAction(startCallAction)
requestTransaction(transaction)
After, in SpeakerBox Project, this function is called :
func provider(provider: CXProvider, perform action: CXStartCallAction)
But not in my project. Then, when i hangup, i see : "Call failed".
Do you have an idea ?
Be sure you are configuring your CXProvider and setting its delegate properly. If you do not set the CXProvider's delegate property, the delegate will not receive any actions to perform.
Also, if you see a "Call Failed" UI, this may indicate your app is crashing. I'd check for crash logs or run the app in the debugger.
As far as I can see, SpeakerBox demo does not perform the following provider method:
https://developer.apple.com/documentation/callkit/cxprovider/1930701-reportcall
func reportCall(with UUID: UUID,
endedAt dateEnded: Date?,
reason endedReason: CXCallEndedReason)
- (void)reportCallWithUUID:(NSUUID *)UUID endedAtDate:(nullable NSDate
*)dateEnded reason:(CXCallEndedReason)endedReason;
Which leads to the "Call failed" UI screen being displayed - as CallKit was not given a reason why the call has ended, and it seems that "
CXCallEndedReasonFailed" is assumed by default.
Call "reportCall endedAt" before requesting the CXEndCallAction transaction to remove "Call failed" screen.
Have you added the required permissions to your info.plist?
When I setup an HKObserverQuery, the update handler always gets immediately called (something I didn't expect). It also gets called when I add data points through Health.app, as you would expect. I am tending to think I am not doing something right with the completion handler, but the docs are fairly sparse on what is supposed to happen here.
Question: Below is basically what I'm doing. Is this expected behavior, or am I missing something?
func listenForUpdates() {
let bodyMassType = HKQuantityType.quantityTypeForIdentifier(HKQuantityTypeIdentifierBodyMass)
let updateHandler: (HKObserverQuery!, HKObserverQueryCompletionHandler!, NSError!) -> Void = { query, completion, error in
if !error {
println("got an update")
// ... perform a sample query to get the actual data
completion() // is this the right thing to do?
} else {
println("observer query returned error: \(error)")
}
}
let query = HKObserverQuery(sampleType: bodyMassType, predicate: nil, updateHandler: updateHandler)
healthStore?.executeQuery(query)
}
Edit: discovered completion handler should only be called when there wasn't an error, so moved into the !error block. An error is present when the app is not authorized.
Yes, this is expected behavior. The update handler will always be called on first execution so that you can use it to fetch your initial data (from your sample query, anchored object query, etc) and populate your UI.
The completion handler is only necessary if you intend to use background delivery, it informs HealthKit that you have received and processed the data you need so that HealthKit knows to stop launching your app in the background. If you have not registered your app for background delivery, then the completion handler is essentially a no-op and you don't need to worry about it.
Been playing around with Uploadify v3 for few days now and just came to realize some of the codes have been rewritten, for example, onError is no longer existed, I am assuming it's been replaced by onUploadError.
What i am trying to achieve is to be able to return non-compliance error to users either through putting a message in the div (preferred method) or alert.
Looking at the closest solution How to trigger uploadify onError event handler, but it's outdated as it's for v2.
Using the same method as the outdated post up there, I have $("#fileInput").uploadify() with onUploadError added:
'onUploadError' : function(file,errorCode,errorMsg) {
var r = '<br />ERROR: ';
switch(errorMsg) {
case 405:
r += 'Invalid file type.';
break;
case 406:
r += 'Some other error.';
break;
}
alert(r);
setTimeout('$("#fileInput'+ ID + 'span.data").html("'+r+'");',111);
}
The problems I am having right now are:
Alert returns undefined using the codes above
setTimeout doesn't do anything
How can you solve these problems?
Maybe it's a little too late... but anyway I try to answer.
I'm also playing around with v3 of uploadify. onError() does no longer exists, it has been replaced by onUploadError(). The erroror object given by the old onError event does no longer exists. Now to check for the type of error you can switch on the errorCode argument (the second given in the callback), which is numeric. I've not found a table with all possible error codes, but doing some trials I discovered the following three error codes:
-200: HTTP errors (e.g. HTTP 500, 400, 404, etc.)
-220: IO errors (e.g. connection closed without response from the server, or errors while rading the source file from the user's PC)
-280: don't have actually fully understood what kind of errors they are, but is seems to be errors gracefully handled by uploadify. For example, if you try to add to the queue a file that is already in the queue, uploadify ask you whether you want to replace the file that's currently enqueued, or cancel the operation. If you cancel, an error is fired with code -280.
To check for the specific type of error, for example to get the specific HTTP error code (in case the error is an http error), you can check the error message, which is the third argument. This argument is a string, not a number, so you cannot use a switch .. case as in your example (or at least it's not that simple to use a switch .. case with strings). Simply use an if .. else if .. else.
Hope this can help...
I'm still looking for a complete list of the possible error codes given in the errorCode argument of the event handler. If someone knows, please tell me!
An onFailure handler in webOS has an argument inError. I tried printing it using: console.log("error: " + inError);, but the result is only: error: [object Object]*** (app/assistants/main-assistant.js:26), which isn't much use. How can I log something more useful instead?
Update:
Ares generates: alarm1Failure: function(inSender, inError) {}. However, the error is contained as the errorText property of the first object and the second object is the request
I would use the interactive debugger at:
http://ares.palm.com/AresDebug/
Connect your device and run your app. Put your app name in the 'Script Filter' box and click get scripts.
Now use the 'Available Scripts' pull down to find your assembly.
You can set breakpoints (click on line numbers to the left) and inspect variables using the lower left pane and '>' prompt.
Be sure to use Chrome or Safari as it will not work with IE.
There is also a logger at:
http://ares.palm.com/AresLog/
if you don't want to use the debugger, then you probably should know something about the inError object getting returned to you. In this case I assume the onFailure comes from a Protocol function's callback, so try looking in the Protocol documentation to see what information the error object should contain.
Also for any logging purposes don't forget about the imensely useful function
JSON.stringify(obj)
It will take an object and return a JSON representation that you can log so you can see all the properties at once.