Do you think I could just leave this part blank and it'd be okay? We're just going to replace the whole thing with a header image anyway, right?
You are not logged in.
When one throws; an exception, it is resource costly.
I wish to prevent this by checking all parameters when logging into a PlayerIO server, e.g. the GameID exists, the username and password exists, the facebook/kongregate account exists, the credentials are right, e.t.c e.t.c before finally logging in.
By checking all of these I hope to prevent an exception BEFORE it happens, and also have a more detailed report to the user on why their specified login failed.
Is there a way to prevent this, or do I have to deal with PlayerIO's costly exception throwing and basic error messages?
@Atilla: ok mr.pie if ur gonna argue about how "modern pc can handle throw; u idiot" pls leave tyvm
Offline
public static Client cli;
public static Connection con;
public static void Connect (string email, string password, string world) {
try {
cli = PlayerIO.QuickConnect.SimpleConnect ("everybody-edits-su9rn58o40itdbnw69plyw", email, password, null);
con = cli.Multiplayer.JoinRoom (world, null);
con.Send ("init");
con.OnMessage += delegate (object sender, Message e) { // ... };
con.OnDisconnect += delegate (object sender, string reason) { // ... };
} catch (Exception error) {
Console.WriteLine (error.Message);
Console.ReadKey (true);
}
}
That's what exceptions are for. To tell you what went wrong.
Offline
can I say the (seeming truth) that you don't want to hear from atilla?
You're talking about potentially a once or twice issue for each user. I feel like what PlayerIO passes in the error message is already pretty verbose.
I guess I don't see the issue adding up. Sidenote: what if you were looping an exception? Does that become a place where you'd want to avoid an exception? Say thousands or millions of tests... hopefully you aren't doing that with the login eh
Offline
So you want to avoid an exception by throwing your own exception? What?
Offline
can I say the (seeming truth) that you don't want to hear from atilla?
^This just killed me
So you want to avoid an exception by throwing your own exception? What?
It might make sense when working with bad libraries,
Say you get a LoginFailedException, and instead would love to have a more detailed InvalidUsernameException.
(I personaly do not know what exceptions PlayerIO throws in these cases)
Offline
So you want to avoid an exception by throwing your own exception? What?
NinjaException
Offline
Hopefully the open source PlayerIO can fix this.
can I say the (seeming truth) that you don't want to hear from atilla?
Yes and no
Because of this http://forums.everybodyedits.com/viewtopic.php?id=37703
Atilla's only argument was "nubs celebrate new year at UTC" of which Atilla clearly doesn't understand religion and symbolic things because they're too scientific.
An entire argument was formed upon "celebrate new year at UTC" when the other argument was "its symbolic bro"
I'd be glad to bring in atilla upon this subject however, as Atilla is one of the develoipers in OPIO and is handling how to check for these sorts of things.
EDIT: wow why have you guys turned this topic into this
So you want to avoid an exception by throwing your own exception? What?
Quote where I said I'd like to throw my own exception.
Offline
You should go learn what an Exception is, know that OpenPIO will throw exceptions the same as PlayerIOClient and any other decent SDK because that's what exceptions are for, and learn how to handle them by using try/catch.
I wish to prevent this by checking all parameters when logging into a PlayerIO server, e.g. the GameID exists, the username and password exists, the facebook/kongregate account exists, the credentials are right, e.t.c e.t.c before finally logging in.
That's exactly what the SDK does for you. If it fails, it'll throw you an Exception telling you what gone wrong (wrong credentials, internet problems, etc.).
Offline
You should go learn what an Exception is, know that OpenPIO will throw exceptions the same as PlayerIOClient and any other decent SDK, and learn how to handle them.
Of course OPIO will throw exceptions, but it will have the code to check where and when to throw the exception.
Offline
HG wrote:You should go learn what an Exception is, know that OpenPIO will throw exceptions the same as PlayerIOClient and any other decent SDK, and learn how to handle them.
Of course OPIO will throw exceptions, but it will have the code to check where and when to throw the exception.
To check where what and when what? It'll throw the exception when executing the code fails, like any other Exception thrown. If you don't want to handle it, it's your fault.
Offline
ninjasupeatsninja wrote:HG wrote:You should go learn what an Exception is, know that OpenPIO will throw exceptions the same as PlayerIOClient and any other decent SDK, and learn how to handle them.
Of course OPIO will throw exceptions, but it will have the code to check where and when to throw the exception.
To check where what and when what? It'll throw the exception when executing the code fails, like any other Exception thrown.
You're clearly not understanding the point of this topic and discussion.
I want to be able to check all various kinds of things before logging in to avoid throwing or catching a costly exception.
I wish to be able to check for everything first to make sure that the exception won't be thrown.
If you have a problem with the fact that I do not wish for an exception to be thrown, please leave, as this wouldn't add any current discussion to the topic, and it'd be two idiots fighting over an opinion of what they both prefer to do and how one is better than the other, when they're clearly both opinions.
Offline
HG wrote:ninjasupeatsninja wrote:HG wrote:You should go learn what an Exception is, know that OpenPIO will throw exceptions the same as PlayerIOClient and any other decent SDK, and learn how to handle them.
Of course OPIO will throw exceptions, but it will have the code to check where and when to throw the exception.
To check where what and when what? It'll throw the exception when executing the code fails, like any other Exception thrown.
You're clearly not understanding the point of this topic and discussion.
I want to be able to check all various kinds of things before logging in to avoid throwing or catching a costly exception.
I wish to be able to check for everything first to make sure that the exception won't be thrown.If you have a problem with the fact that I do not wish for an exception to be thrown, please leave, as this wouldn't add any current discussion to the topic, and it'd be two idiots fighting over an opinion of what they both prefer to do and how one is better than the other, when they're clearly both opinions.
I believe you guys both have a point,
From my experience you would usually want to have an exceptions thrown, and, if necessary, once you catch it understand what went wrong.
Offline
HG wrote:ninjasupeatsninja wrote:HG wrote:You should go learn what an Exception is, know that OpenPIO will throw exceptions the same as PlayerIOClient and any other decent SDK, and learn how to handle them.
Of course OPIO will throw exceptions, but it will have the code to check where and when to throw the exception.
To check where what and when what? It'll throw the exception when executing the code fails, like any other Exception thrown.
You're clearly not understanding the point of this topic and discussion.
I want to be able to check all various kinds of things before logging in to avoid throwing or catching a costly exception.
I wish to be able to check for everything first to make sure that the exception won't be thrown.If you have a problem with the fact that I do not wish for an exception to be thrown, please leave, as this wouldn't add any current discussion to the topic, and it'd be two idiots fighting over an opinion of what they both prefer to do and how one is better than the other, when they're clearly both opinions.
And what are you supposed to do when checking the variables? If a parameter is not correct you'll end getting an Exception anyways.
Who would want to connect to the Player.IO server and check the entire account database to check if the credentials are correct just to prevent any kind of Exceptions you'll end getting because the SDK will throw them to you.
If you want to completely avoid Exceptions, you should not use PlayerIOClient and create your own SDK for that.
What's wrong with Exceptions anyway? You're trying to hide what went wrong to the user to tell him what gone wrong which is exactly what gone wrong when the Exception was thrown.
Offline
SmittyW wrote:So you want to avoid an exception by throwing your own exception? What?
Quote where I said I'd like to throw my own exception.
You said you wanted to avoid a PlayerIO exception and "also have a more detailed report to the user on why their specified login failed" aka throwing your own exception, right? How can you check if an account is valid without some message telling you it is or isn't?
Offline
ninjasupeatsninja wrote:HG wrote:ninjasupeatsninja wrote:HG wrote:You should go learn what an Exception is, know that OpenPIO will throw exceptions the same as PlayerIOClient and any other decent SDK, and learn how to handle them.
Of course OPIO will throw exceptions, but it will have the code to check where and when to throw the exception.
To check where what and when what? It'll throw the exception when executing the code fails, like any other Exception thrown.
You're clearly not understanding the point of this topic and discussion.
I want to be able to check all various kinds of things before logging in to avoid throwing or catching a costly exception.
I wish to be able to check for everything first to make sure that the exception won't be thrown.If you have a problem with the fact that I do not wish for an exception to be thrown, please leave, as this wouldn't add any current discussion to the topic, and it'd be two idiots fighting over an opinion of what they both prefer to do and how one is better than the other, when they're clearly both opinions.
And what are you supposed to do when checking the variables? If a parameter is not correct you'll end getting an Exception anyways.
Who would want to connect to the Player.IO server and check the entire account database to check if the credentials are correct just to prevent any kind of Exceptions you'll end getting because the SDK will throw them to you.
If you want to completely avoid Exceptions, you should not use PlayerIOClient and create your own SDK for that.
What's wrong with Exceptions anyway? You're trying to hide what went wrong to the user to tell him what gone wrong which is exactly what gone wrong when the Exception was thrown.
^1000th post btw
Offline
ninjasupeatsninja wrote:SmittyW wrote:So you want to avoid an exception by throwing your own exception? What?
Quote where I said I'd like to throw my own exception.
You said you wanted to avoid a PlayerIO exception and "also have a more detailed report to the user on why their specified login failed" aka throwing your own exception, right? How can you check if an account is valid without some message telling you it is or isn't?
It is possible to use if-else for comparing the parameters with the server parameters (which would require a lot of hard and completely useless work), but what are you supposed to do at the else part to tell the user what gone wrong without throwing an Exception which contains the detailed information?
It's like creating an Exception for each type of error you can get at the moment of logging in. (InvalidUsernameException, InvalidPasswordException, NoRoomRunningException)
Now, an Exception is a class. Of course we could have returned a string. But how are you supposed to check it then?
Offline
It is possible to use if-else for comparing the parameters with the server parameters, but what are you supposed to do at the else part to tell the user what gone wrong without throwing an Exception?
Pretty sure it breaks down like this.
The sdk does whatever prerequisite testing it wants to, including whatever can go wrong with the login attempt. So naturally you make sure the game exists, the email exists, and that the password matches the email. If any of this fails, it's not going to just return null, it'll throw the exception.
Ninja wants to do the prerequisite testing we mentioned previously. If he does that, he no longer needs to throw an exception. He could, if what he is seeking exists, simply replace the pseudocode "throw exception" lines with "console writeline" lines, if he thinks there's some way he could be more specific.
Yes?
Now, an Exception is a class. Of course we could have returned a string. But how are you supposed to check it then?
Don't they already specify what the problem is via an inner message? Why the extra exceptions?
Offline
I believe you guys both have a point,
From my experience you would usually want to have an exceptions thrown, and, if necessary, once you catch it understand what went wrong.
However, I'd like to check that everything wouldn't be wrong first, to ensure that no exception gets thrown. I'd like to understand the error first before the exception gets thrown, as this would hopefully make a faster login process by informing the user of something incorrect before they login.
And what are you supposed to do when checking the variables? If a parameter is not correct you'll end getting an Exception anyways.
You won't get an exception if you check it before it happens.
Who would want to connect to the Player.IO server and check the entire account database to check if the credentials are correct just to prevent any kind of Exceptions you'll end getting because the SDK will throw them to you.
This is perhaps a very dumb thing to say - clearly I want to based on the current argument
If you want to completely avoid Exceptions, you should not use PlayerIOClient and create your own SDK for that.
Which is why I need to learn how PlayerIOClient works so I can make my own native C++ SDK and incorporate that in a native C++ console application and then we have the most crossplatform bot in the world EE! Brilliant! Add in QT and now it's the most crossplatform GUI bot!
What's wrong with Exceptions anyway?
Me being a low-memory-performance-at-all-costs-save-all-the-memory-memory-lives-matter
Although I don't even know the performance penalties.
Also I hope to achieve faster login by checking everything first.
EDIT:
ninjasupeatsninja wrote:SmittyW wrote:So you want to avoid an exception by throwing your own exception? What?
Quote where I said I'd like to throw my own exception.
You said you wanted to avoid a PlayerIO exception and "also have a more detailed report to the user on why their specified login failed" aka throwing your own exception, right? How can you check if an account is valid without some message telling you it is or isn't?
MessageBox.Show("hey nub ur acc email is bad");
EDIT2:
Closing the topic because I see that my argument is clumsy and nobody is answering the original question.
Offline
Here's a thought. What if the client doesn't break these into a bunch of different checks? What if the call is neatly packaged and sent off to the server as a whole? In that case, there's nothing you can do
If this is wrong, then you won't really gain much. I'm thinking about the individual requests sent off on down the line. Surely your computer can resolve an exception in fractions of the time it takes the round-trip.
also didn't someone tell you the last time you wanted to optimize that .NET is not very small to begin with? You'd be shrinking your portion of an otherwise large setup
Offline
Although I don't even know the performance penalties.
Also I hope to achieve faster login by checking everything first.
Okay I think we're done here. Wrap it up guys
Offline
By checking all the variables before logging in, you will just get a slower, slower log in.
Now, if a parameter is not correct, what do you think you will get that tells you that the parameters was wrong, apart from an Exception? Which error are you trying to understand if you have no Exception that tells you what gone wrong?
Offline
[ Started around 1732727037.9315 - Generated in 0.146 seconds, 12 queries executed - Memory usage: 1.81 MiB (Peak: 2.08 MiB) ]