Let's say I have a test with following assertion:
assertThat(response.isSuccess()).as(response.errorBody().string()).isTrue();
it will throw NullPointerException when response is success therefore test never passes.
I needed to make soemthing like this:
String errorDescription = response.errorBody() == null ? "" : response.errorBody().string();
assertThat(response.isSuccess()).as(errorDescription).isTrue();
which is ugly. Is it possible for errorBody to be wrapped in optional or maybe there is a better way for doing this?
Someone deleted my answer to that saying that I provided only url to github where it was answered. This was my answer to post:
Answered on github of Retrofit: https://github.com/square/retrofit/issues/1304
Optionals are not available on Android.
This time I emphasized actual answer so it will not be deleted again.
Related
I am trying to integrate PayU in my website, I have successfully done the payment api part. Now I am trying to call verification api of transaction. I have followed all the steps from documentation.
Method POST:https://test.payu.in/merchant/postservice?form=2
Image
I am getting, Sorry Some Problem Occurred without any proper error message.
I am stuck on this. Please help.
Any help or comment will be highly appreciated.
My code: Function to make string(in expected format given in the documentation) and Hash using SHA256
{ string command = "verify_payment";
string finalStringToBeHashed = PAYU_KEY +"|"+ command + "|" + transactionId + "|" + PAYU_SALT;
string hash = _iPayUServices.GetSHA256(finalStringToBeHashed);
return Ok(( hash, finalStringToBeHashed));
}
and I am confident that my GetSHA256() function is correct. (As it working for payment api's).
Instead of https://test.payu.in/merchant/postservice?form=2 URL,
use https://info.payu.in/merchant/postservice?form=2.
Actually They are upgrading their documentation, so many things are missing as of now. Hopefully, they will add this soon.
I expected
await queue.get()
to be blocking in aio_pika, but even when I don't set the timeout parameter I instantly get an error:
aio_pika.exceptions.QueueEmpty
Anyway to get a blocking get in aio_pika?
EDIT:
This is the best I could come up with so far.
while True:
msg = await q.get(fail=False)
if msg:
break
await asyncio.sleep(1)
The RabbitMQ team monitors the rabbitmq-users mailing list and only sometimes answers questions on StackOverflow.
You should use a very long timeout, according to the documentation for that method. There does not appear to be another way to do it.
I am using "meteor.loginWithPassword" in my website for logging in but in the matter of fact I always get the error : "Match failed".
I do not find the reason why?
I have the user I am testing in my Database. I read somewhere that it is because one of the fields are empty, but this is not the reason.
I don`t know what should I check?
Template.login.events({
'submit form': function(event){
event.preventDefault();
var username = $('[name=username]').val();
var password = $('[name=password]').val();
Meteor.loginWithPassword(username, password, function(error){
console.log(error);
});
}
});
How to understand the error
When you're getting a Match error that's ultimately from the 'meteor/check' library.
So what you want to solve is "what Match conditions does the Meteor.loginWithPassword method expect". This will tell you what argument values will be permitted at runtime.
To answer that question you can look here https://github.com/meteor/meteor/blob/devel/packages/accounts-password where the code that sets up that method is defined.
NOTE: code references from here on arbitrarily reference version 2.5.8 to keep line references. However you could search under the version your code is at in essentially the same place
More specifically you're interested in the check call here https://github.com/meteor/meteor/blob/release/METEOR%402.5.8/packages/accounts-password/password_server.js#L170,#L173.
Bonus Round
It's worth noting that even if you were crawling the source code and found where Meteor.loginWithPassword is defined here https://github.com/meteor/meteor/blob/release/METEOR%402.5.8/packages/accounts-password/password_client.js#L33 it wouldn't be super obvious that the method call there gets picked up by the handler here https://github.com/meteor/meteor/blob/release/METEOR%402.5.8/packages/accounts-password/password_server.js#L166.
As it turns out the handlers match on the shape of arguments not the name 🙃.
I'm having a doozie of a time trying to get a basic http test to work with vows.
I think I've followed the async example from vows http://vowsjs.org/#-writing-asynchronous-tests and substitued the appropriate calls, but I must be missing something.
The test code looks like this:
var http = require('http'),
vows = require('vows'),
assert = require('assert');
vows.describe("homepage").addBatch({
"Get the home page": {
topic: function() {
http.get({'host': "127.0.0.1", 'port': 5000, 'path': '/'}, this.callback);
},
'should respond with 200 OK': function(res) {
assert.equal(res.statusCode, 200);
}
}
}).export(module);
I get the following error when I try to run the test for this:
/Users/<home_folder>/node_modules/vows/lib/vows.js:80
rrored', { type: 'promise', error: err.stack || err.message || JSON.stringify(
^
TypeError: Converting circular structure to JSON
at Object.stringify (native)
at EventEmitter.<anonymous> (/Users/<home_folder>/node_modules/vows/lib/vows.js:80:90)
at EventEmitter.emit (events.js:64:17)
at /Users/<home_folder>/node_modules/vows/lib/vows/context.js:31:52
at ClientRequest.<anonymous> (/Users/<home_folder>/node_modules/vows/lib/vows/context.js:46:29)
at ClientRequest.g (events.js:143:14)
at ClientRequest.emit (events.js:64:17)
at HTTPParser.onIncoming (http.js:1349:9)
at HTTPParser.onHeadersComplete (http.js:108:31)
at Socket.ondata (http.js:1226:22)
I can get a simple http example to work on it's own. I can get the vows example to work on it's own but I can't combine them for whatever reason. I'd really appreciate some help here. I've been trying to get this to work for a while now (including much googling).
UPDATE:
Apparently adding an error argument to the call back solves this problem, thanks to help from Alexis Sellier (creator of vows).
But I have no idea why. When writing out the http lib example on it's own no error argument is required. I can't find any documentation in vows to indicate why it's needed so I'm at a bit of a loss.
My new question is why is the error argument required when using the http lib in vows?
After checking vow's source code, I think I know why. Vows always ensure that when you call this.callback, the resulting receiver function's first argument is always an error object. Vows interpret the callbacks by these rules:
If the first argument of your originating callback is a boolean, use that to determine whether or not to append an error object to the receiving callback (e.g. path.exists(boolean) will emit callback(error, exists) instead)
If the first argument is an object, assume it's an error object and use that to determine whether to add the originating callback to the "error" or "success" list. The reason this list exists is to support promise based tests I guess?
While I can't confirm the above is correct, my experience is that vows' async style is made to support node-styled callbacks (e.g. err as the first arg), and 3rd party npm modules that don't conform to this standard will be hard to test.
Please don't take my answer as gospel, as this is my own experience. Another gotcha is when you have async operations inside the function that you want to test - unless you provide a callback, vows won't be able to handle it properly.
Personally, I think vows still make it hard to test async code. I wish it had some waitFor() or until() flow control functions though.
My suggestion? When dealing with async code, use Step. Don't let vows control your flow.
It is actually missing in the documentations which is still a bit short. But you can get a glimpse of it here in this page :
'when peeled *asynchronously*': {
topic: function (banana) {
banana.peel(this.callback);
},
'results in a `PeeledBanana`': function (err, result) {
assert.instanceOf (result, PeeledBanana);
}
}
As it was said by Morten Siebuhr and Ruben Tan, this is how vows works and that is why it works like that.
What does statement "insert" in SQLite return in case of success?
I always believed that it should be SQLITE_DONE, but recently in my logs I found out the following string:
sqlite3_step error: 'not an error'
And here is the code that logs the mentioned string:
prepareStatement(addTranslationStmt2, "INSERT INTO translations(lang1_wordid, lang2_wordid) VALUES(?, ?)");
if (!addTranslationStmt2) return -2;
sqlite3_bind_int(addTranslationStmt2, 1, word_id);
sqlite3_bind_int(addTranslationStmt2, 2, translation_id);
if(sqlite3_step(addTranslationStmt2) != SQLITE_DONE)
{
NSLog(#"sqlite3_step error: '%s'", sqlite3_errmsg(database));
sqlite3_reset(addTranslationStmt2);
return -1;
}
sqlite3_reset(addTranslationStmt2);
I am wondering, why does it work in most cases.
Should I change SQLITE_DONE in my code to SQLITE_OK?
Thanks.
SQLITE_DONE
http://www.sqlite.org/c3ref/step.html
You could also try printing out the error code to find out what the problem is.
In cases like these, I like to look at code samples. Here are some good ones:
http://sqlite.phxsoftware.com/forums/p/76/6659.aspx
The SQLite Result Codes Reference lists SQLITE_OK as indicating a successful result. It is also the first error code, having an error code of 0, making it the canonical result (i.e. the result I would expect on a successful operation).
You should put a breakpoint or print statement in your code to find out if it really is returning zero, and check your data to make sure you're getting the result you expect. If that all checks out, I would change your condition to check for SQLITE_OK.
The details of the behavior of the sqlite3_step() interface depend on whether the statement was prepared using the newer "v2" interface sqlite3_prepare_v2() and sqlite3_prepare16_v2() or the older legacy interface sqlite3_prepare() and sqlite3_prepare16().
In the legacy interface, the return value will be either SQLITE_BUSY, SQLITE_DONE, SQLITE_ROW, SQLITE_ERROR, or SQLITE_MISUSE. With the "v2" interface, any of the other result codes or extended result codes might be returned as well.
Switching from "Debug" configuration to "Release" resolved the issue for me.