After upgrading to Vaadin 23.0.x (from former 22.0.2) I now keep getting the following error when opening a certain dialog:
2022-08-01 18:56:25,977 ERROR [http-nio-8085-exec-5] net.mmo.utils.kism.ui.views.nodes.NodeView: java.lang.IllegalStateException: All bindings created with forField must be completed before calling readBean
at com.vaadin.flow.data.binder.Binder.checkBindingsCompleted(Binder.java:3070)
at com.vaadin.flow.data.binder.Binder.readBean(Binder.java:2110)
at net.mmo.utils.kism.ui.views.nodes.NodeForm.readBean(NodeForm.java:487)
at net.mmo.utils.kism.ui.views.nodes.NodeForm.setNode(NodeForm.java:211)
This dialog has worked perfectly fine since I wrote it (using version 18.0.x about 2 years ago) and up to v22.0.2. I can't make sense of that error message and I don't understand what the issue could be here. I verified that issue going back and forth and the difference is really only the Vaadin version upgrade. Before it, the dialog works just fine and after it I get the above Exception when opening it.
I also can't quite believe what I think the message is stating here: if it would indeed check that I define or complete any bindings AFTER calling Binder.readBean() - how could it know that already in that very moment, i.e. when the code calls readBean() - as indicated by the stacktrace?
If there would indeed be any bindings being defined afterwards, IMHO it could only find that out AFTER said readBean()-call, i.e. when any additional bindings were actually defined, couldn't it?
So, could someone please try to "translate" or explain that issue or the background behind it to me?
The error basically states the problem: in the process of binding a field to a property (or getter/setter in general), the finishing step of actually binding was not undertaken. So the process was started with .forField() but never finished by .bind().
Since the error message as of now only states the fact, but not the culprit, a developer would be in need of a debugger to inspect the private state of the Binder, where the map incompleteBindings holds the current state of the Binder. The content of this map may help to find the culprit, e.g. by only holding one entry and by inspecting the flow of the program so far, that would conclude, what binding attempt failed. Or e.g. via the included field types.
Other than plain "bugs" by the developer, there are some potential reasons, why this suddenly happens by like an update or what places to look for:
multiple (re-)binding was recently added (e.g. to first bind "automatically" and then hand-tune the result); this holds potential, that older versions of the code just kept the initial binding and ignored the dangling second process.
the binding process uses a builder pattern; builder must build up on the result of the previous steps. This means, that in imperative code, there is the chance, that this chained call miss reassigning the build step. E.g.
var b = binder.forField(field)
if (predicate)
b.asRequired() // XXX: should be `b = b.asRequired()`
b.bind(...)
(this may or may not be a source for this kind of problem, but it's good to point out here, since the binder builder implementation actually switche(s|d) the builder (in the past)
At runtime, when listing the classes in my main bundle (using objc_getClassList). I see things like :
_TtGCs18ManagedProtoBufferVs29_HashedContainerStorageHeaderVs5UInt8_
_TtGCs13ManagedBufferVs29_HashedContainerStorageHeaderVs5UInt8_
_TtGCs28_NativeDictionaryStorageImplCSo8NSObjectPs9AnyObject__
_TtGCs18_HeapBufferStorageVs18_StringBufferIVarsVs6UInt16_
Any ideas what those are??
Also, they do not always appear...
I also see NSKVONotifying_NSUserDefaults sometimes.
I finished writing a class' .h and .m files in objective c in XCode and want to see if all the class functions are implemented correctly. I have not set up anything in the storyboard file yet but would like to test and debug the code. I'm looking to simply declare an object of the class type and to run some of the functions on it similar to using the command line with Python.
If there's no way to simply debug code using command line commands, what would be the easiest way to set up the storyboard?
You can use the XCTest to test your classes.
You can find all the information you need in the Apple documentation is actually pretty easy to use.
https://developer.apple.com/Library/ios/documentation/DeveloperTools/Conceptual/testing_with_xcode/testing_2_testing_basics/testing_2_testing_basics.html#//apple_ref/doc/uid/TP40014132-CH3-SW1
If you want you can check this tutorial as well.
http://rshankar.com/test-driven-development-in-ios-beginners-tutorial-part-1/
If you want you can set break points as well and check that your code is executing properly. Sometimes when I just want to proof-test small classes I do it just setting a couple of break points instead of the XCTest classes but it all depends on your study case. If you have a decent amount of classes I would suggest to use XCTest to check that the classes are actually doing what is expected setting your assertions and the other conditions that XCTest offers as a framework.
Another way you can do your testing if applicable is using NSLog to print in console lines or values of interest at each stage of your code execution.
You mentioned the command line. If you set breakpoints you can use po objName to print the value or print varName to check values of objects and primitive variables correspondingly. po stands for print object and print well... There's different options if you feel comfortable using the console just set NSLogs at certain point of your code or set the break points and print the values using po or print commands in the console.
Here you can check the string format specifiers for NSLog which are the same ones used for NSString
https://developer.apple.com/library/ios/documentation/cocoa/conceptual/Strings/Articles/formatSpecifiers.html
I'm now programming ios apps for a while. But still my apps crash regularly and it takes time to make them very stable. I find this very annoying.
So, are there any programming patterns regarding crash proof programming ios app?
Turn up the compiler warnings. Remove all warnings.
Run the static analyzer. Remove all warnings.
Run with GuardMalloc and/or Scribbling.
Remove all Leaks
Remove all Zombies
Write Unit Tests
Write a high level of live error detection (e.g. assertions)
Fix bugs before adding features.
Use source control and continuous integration.
Read. Improve.
1) Use ARC.
ARC has a small learning curve, and the big problem I read about on SO is that people instantiate objects but forget to assign the object to a strong ivar (or property), so the object mysteriously goes away. In any case the benefit is so compelling you should master this. When you do, most of all the memory management stuff you have to keep straight now goes away.
2) Build clean
You should never ever have warnings when you build. If you have a bunch, when a real problem comes up, it gets buried in the lines of cruft you got use to ignoring. Professional programmers build clean.
3) Use Analyze
Xcode/llvm has a phenomenal analyzer - use it - its under the Product menu item. Then clean up every single warning it gives you.
4) Use the right Configuration
I always have a Release (or Distribution) configuration, a ReleaseWithAsserts, and Debug. I only use Debug when using lldb, as the code is much bigger and it will execute differently than an optimized compile will. ReleaseWithAsserts is similar to Debug, but the Debug=1 preprocessor flag is removed, and the optimizer is set to -Os (the default for Release).
Finally, the Release/Distribution configuration has the following in the Preprocessing Macros:
NS_BLOCK_ASSERTIONS=1 NDEBUG
The first turns off all 'NSAssert()' lines, and the second all 'assert()' statements. This way no asserts are active in your shipped code
5) Use copious amounts of asserts.
Asserts are one of the best friends you can have as a programmer. I see sooooo many questions here that would never get written if programmers only would use them. The overhead is in typing them, since (in my usage) they are compiled away in the Release configuration.
Whenever you get an object from another source, assert its existence (ie:
MyObject *foo = [self someMethod];
assert(foo);
This is sooo easy to type, but will save you hours of debugging when a nil object causes problems thousands of instructions later. You can assert on class too:
MyObject *foo = [self someMethod];
assert([foo isMemberOfClass:[MyObject class]]);
This is particularly useful when you are pulling objects out of dictionaries.
You can put asserts at the start of methods, to verify that you received objects not nil too.
You can assert that some variable has a value:
assert(i>1 && i<5);
Again, in all but the Release/Distribution configuration, the assert is "live", but in that configuration they are compiled out.
NSAssert is similar - but you have to use different macros depending on the number of arguments.
NSAssert(foo, #"Foo was nil");
NSAssert1(foo, #"Foo was nil, and i=%d", i);
...
6) Use selective Logs to insure that things that should happen are
You can define your own Log macro, which gets compiled out for Release/Distribution. Add this to your pch file:
#ifndef NDEBUG
#define MYLog NSLog
#else
#define MYLog(format, ...)
#endif
This points up another point - you can use:
#ifndef NDEBUG
...
#endif
to block out a bit of code that does more complex checks - and its just active for your development builds, not for Release/Distribution.
You may already do these, but here's what I do:
Go to every screen in the app using the debugger/simulator, and select "Simulate Memory Warning". Go back to the previous screen. This causes existing UIView objects and variable assignments in viewDidLoad to be reassigned (which could result in bad pointer references).
Make sure to invalidate any running timers in the dealloc.
If an object A has made itself a delegate of object B, make sure to clear it in the dealloc for object A.
Make sure to clear any notification observers in the dealloc.
I have to ask this, because: The only thing I recognize is, that if the assertion fails, the app crashes. Is that the reason why to use NSAssert? Or what else is the benefit of it? And is it right to put an NSAssert just above any assumption I make in code, like a function that should never receive a -1 as param but may a -0.9 or -1.1?
Assert is to make sure a value is what its supposed to be. If an assertion fails that means something went wrong and so the app quits. One reason to use assert would be if you have some function that will not behave or will create very bad side effects if one of the parameters passed to it is not exactly some value (or a range of values) you can put an assert to make sure that value is what you expect it to be, and if it's not then something is really wrong, and so the app quits. Assert can be very useful for debugging/unit testing, and also when you provide frameworks to stop the users from doing "evil" things.
I can't really speak to NSAssert, but I imagine that it works similarly to C's assert().
assert() is used to enforce a semantic contract in your code. What does that mean, you ask?
Well, it's like you said: if you have a function that should never receive a -1, you can have assert() enforce that:
void gimme_positive_ints(int i) {
assert(i > 0);
}
And now you'll see something like this in the error log (or STDERR):
Assertion i > 0 failed: file example.c, line 2
So not only does it safe-guard against potentially bad inputs but it logs them in a useful, standard way.
Oh, and at least in C assert() was a macro, so you could redefine assert() as a no-op in your release code. I don't know if that's the case with NSAssert (or even assert() any more), but it was pretty useful to compile out those checks.
NSAssert gives you more than just crashing the app. It tells you the class, method, and the line where the assertion occurred. All the assertions can also be easily deactivated using NS_BLOCK_ASSERTIONS. Thus making it more suitable for debugging. On the other hand, throwing an NSException only crashes the app. It also does not tell about the location of the exception, nor can it be disabled so simply. See the difference in the images below.
The app crashes because an assertion also raises an exception, as the NSAssert documentation states:
When invoked, an assertion handler prints an error message that
includes the method and class names (or the function name). It then
raises an NSInternalInconsistencyException exception.
NSAssert:
NSException:
Apart from what everyone said above, the default behaviour of NSAssert() (unlike C’s assert()) is to throw an exception, which you can catch and handle. For instance, Xcode does this.
Just to clarify, as somebody mentioned but not fully explained, the reason for having and using asserts instead of just creating custom code (doing ifs and raising an exception for bad data, for instance) is that asserts SHOULD be disabled for production applications.
While developing and debugging, asserts are enabled for you to catch errors. The program will halt when an assert is evaluated as false.
But, when compiling for production, the compiler omits the assertion code and actually MAKE YOUR PROGRAM RUN FASTER. By then, hopefully, you have fixed all the bugs.
In case your program still has bugs while in production (when assertions are disabled and the program "skips over" the assertions), your program will probably end up crashing at some other point.
From NSAssert's help: "Assertions are disabled if the preprocessor macro NS_BLOCK_ASSERTIONS is defined."
So, just put the macro in your distribution target [only].
NSAssert (and its stdlib equivalent assert) are to detect programming errors during development. You should never have an assertion that fails in a production (released) application. So you might assert that you never pass a negative number to a method that requires a positive argument. If the assertion ever fails during testing, you have a bug. If, however, the value that's passed is entered by the user, you need to do proper validation of the input rather than relying on the assertion in production (you can set a #define for release builds that disables NSAssert*.
Assertions are commonly used to enforce the intended use of a particular method or piece of logic. Let's say you were writing a method which calculates the sum of two greater than zero integers. In order to make sure the method was always used as intended you would probably put an assert which tests that condition.
Short answer: They enforce that your code is used only as intended.
It's worthwhile to point out that aside from run time checking, assert programming is a important facility used when you design your code by contract.
More info on the subject of assertion and design by contract can be found below:
Assertion (software development)
Design by contract
Programming With Assertions
Design by Contract, by Example [Paperback]
To fully answer his question, the point of any type of assert is to aid debugging. It is more valuable to catch errors at their source, then to catch them in the debugger when they cause crashes.
For example, you may pass a value to a function expects values in a certain range. The function may store the value for later use, and on later use the application crashes. The call stack seen in this scenario would not show the source of the bad value. It's better to catch the bad value as it comes in to find out who's passing the bad value and why.
NSAssert make app crash when it match with the condition. If not match with the condition the next statements will execute. Look for the EX below:
I just create an app to test what is the task of NSAssert is:
- (void)viewDidLoad {
[super viewDidLoad];
// Do any additional setup after loading the view, typically from a nib.
[self testingFunction:2];
}
-(void)testingFunction: (int)anNum{
// if anNum < 2 -> the app will crash
// and the NSLog statement will not execute
// that mean you cannot see the string: "This statement will execute when anNum < 2"
// into the log console window of Xcode
NSAssert(anNum >= 2, #"number you enter less than 2");
// If anNum >= 2 -> the app will not crash and the below
// statement will execute
NSLog(#"This statement will execute when anNum < 2");
}
into my code the app will not crash.And the test case is:
anNum >= 2 -> The app will not crash and you can see the log string:"This statement will execute when anNum < 2" into the outPut log console window
anNum < 2 -> The app will crash and you can not see the log string:"This statement will execute when anNum < 2"