Hi I'm trying to verify the user email with parse, I been searching the entire web for hours and have found nothing. Everything else with parse is working great! but when I trying to check if the email verification is true, I get this error:
fatal error: unexpectedly found nil while unwrapping an Optional value
basically I'm trying to check that first so I can change to a different viewController, the code that I'm using right now is this...
if user.objectForKey("emailVerified")!.boolValue == true
{
performSegueWithIdentifier("tarjetaCredito",sender: self)
}
I been trying all type of code and I always get the same error, any help? I'm using Xcode 7.0 beta 6
When you see “unexpectedly found nil” in Swift, you can trace it to an exclamation point. (Whether it’s a bare ! or as! or try!, the exclamation point essentially says, “Hey compiler, I know you think an error could happen here, but I know it will never actually happen, so don’t force me to deal with the error case.”)
In your code, the ! is right here:
if user.objectForKey("emailVerified")!.boolValue == true
⬆︎
…which means that the result of the expression user.objectForKey("emailVerified") must be nil. Figure out why that expression is nil, and you’ll have your answer.
If user is a Dictionary, then perhaps there is no value for the key "emailVerified", and perhaps you are using the wrong key string. (Aside: you may be able to say user["emailVerified"] instead, depending on what the type of user is.)
Whatever the cause, printing out the value of user on the line before the crash is likely to help you diagnose the problem:
print("----------> user = ", user)
if user.objectForKey("emailVerified")!.boolValue == true
...
In general, it is often good practice in Swift to avoid using ! — or at least carefully consider why you are using it. If you determine that it is sometimes valid for that expression to evaluate to nil — for example, it might be nil if the email is not validated yet — then you might use ? instead; for example:
if user.objectForKey("emailVerified")?.boolValue == true
Related
This question already has answers here:
Uncaught Error/Exception Handling in Swift
(2 answers)
Closed 5 years ago.
Is it somehow possible to handle a fatal error (of any kind) in iOS? I am not looking for some magical way to make the app stay alive, just some way to inform the user that something went wrong before the app disappears (like an alert for example).
A fatal error is a runtime error. You do not catch fatal errors, because they indicate a programming error, you should fix your code instead. Crashes are built in such a way so that you cannot stop them unless you fix the error in your code. Letting the user know that something went wrong cannot be done and wouldn't help anyway, unless you make it work properly.
To prove that they cannot be stopped, unless you change your code, we can put something that would cause a fatal error in a do-try-catch structure:
do{
var car: String? = nil
try print(car!)
}
catch{
print("Something went worng")
}
Obviously, this still crashes with:
fatal error: unexpectedly found nil while unwrapping an Optional value.
So you must repair your program instead.
While there is no way to inform the user directly of the error, since you would be printing in the console, using a guard statement will help you to avoid fatal errors by checking if the optional value exists in the first place, and returning early if the optional value does not exist. This will save your app from crashing at times.
When something goes wrong like unwrapping nil, two situation may happen. If there are correct try catch around and the error is caught, then your app will continue working. Otherwise, you will end up having a fatal error that crash your app. So a fatal error is a consequence of lacking exception handling and is not something you can stop and show user something before the crash happens.
Just like others mentioned, fatal errors should NEVER occur. Do everything you can to prevent that error from happening.
You can prevent them using do catch blocks and by handling optionals correctly. I would recommend you to read Apple's documentation on that! Good luck!
I am doing a number of business logic checks within the mutateAndGetPayload function of a relay mutation using the graphql-relay library. For any of these checks that fail I have an else clause that will throw an error, ig throw('You do not have permission to delete this resource');, however, when that happens, I get the error Cannot set property 'clientMutationId' of undefined returned to the frontend instead of the error I'm trying to return. It seems that I'm seeing this error because I'm not returning something this mutation cares about (or a promise that resolves to one), so I'm a little stumped ... what's the proper way to throw/return errors back to the client here?
One way is to use the GraphQLError Type
Working in NodeJS on the back end we have used the following library:
https://github.com/graphql/graphql-js/tree/master/src/error
However, what we have ended up using is a library that provides more flexibility:
https://github.com/kadirahq/graphql-errors
Either of these would be the best place to start.
I'm updating a node and pushing it:
remote_graph.push(node)
push() seems to return nothing. How can I tell if the push works? In my test code, I ought to be violating a unique constraint in Neo4J.
How can I tell using py2neo? I expected an exception.
When I enter the equivalent cypher into the Neo4J web tool, I get the following exception:
Node 322184 already exists with label VERSION and property "version"=[1.436818928448956E9]
which is what I expected.
Edit -
What I expected to get back was an indicator of whether the operation worked or not. I think push() accepts an array of nodes, so an array of results would be sensible. I don't know what the indicator would have within it since I don't know what is available. An array of strings would be fine, with each string being a failure reason, or "OK".
Generally speaking, the design of this API is: if it returns OK, you can assume everything has worked as expected, if an error is raised, that error will contain details of what went wrong. Therefore, absence of error should usually be interpreted as a signal of success.
That said, if you believe that your push has failed and no error has been raised, there is a bug in py2neo. For debugging, you can check the state of the database after your push by using the browser and then if you're able to recreate this scenario in a standalone piece of code, please raise an issue on GitHub and I will be happy to fix it.
Please note I'm using a nightly build of Rust 0.13.0
First off, I'm a beginner to Rust and am still in the process of consuming as much information as possible on the language. Throughout my consumption the one topic I've been able to find very little on is error handling. So, when I first attempted to use an external library in my code I became quickly stumped at how I should be using the material being returned to me.
To help explain my confusion, I will be referencing the rust-url library. Here is some sample code found in the documentation:
use url::{Url, InvalidIpv6Address};
assert!(Url::parse("http://[:::1]") == Err(InvalidIpv6Address))
This is pretty straight-forward to me. However, my next question was: what about the other errors? I looked further into the ParseError enum and found 15+ other types of errors that could be potentially produced by a malformed URL.
So, my question is, what is considered the proper way to handle all of these various conditions? Should I have a lengthy match that alerts out specialized messages for each one? Is there a way to consume them all at once?
I apologize if there is not a single answer to this question, but Google was not making it clear and I would prefer to have feedback on this before I proceed coding the rest of my project the wrong way.
The ParseError enum implements the Show trait, with a custom useful message for each variant, so when you get to the final step of actually handling the parse error (e.g. after manipulating the Result in whatever ways you see fit), you can just treat the error possibilities as a black box:
fn download(s: &str) {
match Url::parse(s) {
Ok(url) => { ... }
Err(e) => {
println!("Could not parse '{}'. {}.", s, e);
}
}
}
will print things like Could not parse 'http://[:::1]'. Invalid IPv6 address..
(I filed #43 about making the Show message lower-cased, so that it flows better in more complicated error messages.)
Url::parse returns ParseResult<Url> which is defined as Result<Url, ParseError>, so you can make use of generic Result methods:
use url::{Url, InvalidIpv6Address};
assert!(Url::parse("http://[:::1]").is_err());
Result is Rust's preferred method for error handling, and has many convenience methods under the hood. For example, if you don't expect the failure you can use .unwrap() to make any failure fatal. When they don't suit your needs, you can also match against the Result.
I am working on a script that allows user entry of Lua (specifically, boolean conditionals), and I am trying to provide a feature that will perform a quick error check for the script that is entered.
It's easy enough to throw an error if loadstring() fails, so syntax issues are readily handled.
However, if variables are improperly entered, it is harder to detect a problem.
Let's say the user enters the following:
value.custom_value_1 == 1 and valse.custom_value_2 ~= 1
As far as the syntax goes, loadstring() is quite satisfied -- it adds 'return ' as a prefix to that string.
My next step is to check for errors when we execute what was entered by the user. The problem is, when value.custom_value_1 ~= 1, the logic will short-circuit since we're dealing with and - there's no point in going further, we already have false on the left-hand side.
What I would like is to find a way to cause Lua to completely evaluate the expression, rather than short-circuiting. If it did so, the spelling error valse would be caught (regardless of value.custom_value_1's value) and I can provide an error message to the end user.
Any thoughts?
My current best idea is to filter through the user input, sorting out every value entered (basically, whatever's not an a conditional or, and, ...) and just doing it manually. But I thought it's worth checking to see if there's a better way.
Preventing short-circuit evaluation is not something you would want to / could do. That's just the way it works.
What you could do instead is something like:
if(logic1 and logic2)
{
// code on success
}
else
// check what kind of error we have
{
if(~logic1)
{
// throw error type 1
}
if(~logic2)
{
// throw error type 2
}
}
If you don't mind parsing the string up-front you could use a library like https://github.com/stravant/LuaMinify/blob/master/ParseLua.lua to parse the source into an AST, modify the short-circuiting notes into function calls like
function my_and(x, y)
return x and y
end
Then you compile this AST to check for the errors.
Seems a lot hassle though just to catch trivial errors.
I'm not sure if anyone's answer was accurate, but the literal question was 'can you prevent short-circuit evals' and I was not able to find a way to do that.
I ultimately chopped up the user input and tested each component individually, gathering those errors and feeding them back to the user. Seems okay for now.