I have a unit test that tests if method throws an exception when condition is present, and method does throws exception as expected.
- (void)testMethodThrowsWhenConditionIsPresent {
XCTAssertThrows([Foo methodWithCondition: condition], #"Condition is true, method should throw exception");
}
Here is the exception source:
- (void)methodWithCondition:(someType)condition {
if (condition) {
[NSException raise: #"condition is true!" format: #"condition is true!"];
}
}
Why does the test stop at the line the exception is thrown? The test does not go on, it stops at that line, when I expect it to continue and return 1 from XCTAssertThrows(), making the test succeed. The test instead stops with Xcode bringing me to the line it was thrown, with a green `Thread 1: breakpoint 1.1' and the debugger appearing in the console.
Why does the test stop when the execution is thrown?
Because you have a breakpoint, which stops execution.
Why, after removing the breakpoint, does my application crash when the exception is thrown?
Because you have an unhandled exception. Unhandled exceptions cause your program to crash.
How can I handle an exception so it won't crash my program?
The easy answer to this question is to simply NOT throw an exception. In other programming languages, like Java, this is perfectly standard. But in Objective-C, we don't really do exceptions. In Objective-C, exceptions should be saved for TRULY exceptional behavior.
With that said, and a strong suggestion for you to find another way to handle whatever it is you're trying to handle, this is how you handle an exception in Objective-C:
#try {
// code that could throw an exception
}
#catch (NSException *e) {
// handle the exception...
}
#finally {
// post try-catch code, executed every time
}
Related
Scenario: Below negative scenario to be tested during Integration test. currently the test case getting failed due exit and not reaching to the test method.
example :
private void method1(int a){
try{
if(a == 0){
throw exception();
}else{
---
}
}catch(exceptionclass e){
System.exit(1);
}
}
Sound like a bad smell to me that calling a method on a object can cause JVM to exist. Normally it should be done in the main method.
So I would refactor your codes such that your testing object will throw a kind of Exception to indicate that some kind of fatal error happens such that the main method can catch it and terminate the JVM.
Then you can simply test that if it will throw this Exception from your test case.
As per kotest docs: https://github.com/kotest/kotest/blob/master/doc/nondeterministic.md
You can tell eventually to ignore specific exceptions and any others will immediately fail the test.
I want to pass multiple exceptions to eventually that I know would be thrown by my block so that I can explicitly skip them.
Right now I only see a way to pass one, how do I pass more than one exception to eventually to skip it in case the block throws those exceptions?
You may use superclass for all your exceptions like
eventually(200.milliseconds, exceptionClass = RuntimeException::class) {
throw IllegalStateException()
}
or wrap exceptions
eventually(200.milliseconds, exceptionClass = IllegalStateException::class) {
runCatching { throw UnknownError() }
.onFailure { throw IllegalStateException(it) }
}
In 4.4.3 there are no features with collection of Exception
Using rxJava 1.1.3, when throwing an exception in the onCompleted handling, the onErroris not called nor is the error propagated to the calling thread. It simply disappears.
As an example consider the following spock test:
def "when a onCompleted throws an IllegalStateException, it's handled by the onError handler"() {
given:
boolean onErrorCalledFromSubscribe = false
when:
Observable.just(1, 2, 3)
.subscribe(
Actions.empty(),
{ onErrorCalledFromSubscribe = true},
{throw new IllegalStateException("I'm behaving badly")})
then:
noExceptionThrown()
onErrorCalledFromSubscribe == true
}
The above test fails because onErrorCalledFromSubscribe is never called and is false at the end of the test.
Now, I can imagine that once onCompleted is called, onError shouldn't be called because either the one or the other should be called.
However, I wonder how do you handle such situations where a RuntimeException is called in your onCompleted method and you want to handle the error.
Do you simply wrap the onCompleted call in a try-catch and handle the error there?
Just use a try-catch in onCompleted if you think there might be an exception thrown in there.
As I mentioned in the comments, RxJava should not be swallowing exceptions from onCompleted but currently is; still, if you know that there is going to be the possibility of an exception, you should just handle it yourself.
I have a problem with the following code example:
Windows::Storage::StorageFolder^ location = Package::Current->InstalledLocation;
try
{
task<StorageFile^> GetFileTask(location->GetFileAsync(sn));
GetFileTask.then([=](StorageFile^ file)
{
try
{
task<IBuffer^> ReadFileTask(FileIO::ReadBufferAsync(file));
ReadFileTask.then([=](IBuffer^ readBuffer)
{
// process file contents here
});
}
catch(Platform::Exception^ ex)
{
// Handle error here
}
});
}
catch(Platform::Exception^ ex)
{
// Handle error here
}
When using a filename that doesn't exist the function throws an exception:
Unhandled exception at 0x0FFCC531 (msvcr110d.dll) in GameTest2.exe: An invalid parameter was passed to a function that considers invalid parameters fatal.
I've been searching the internet and this exception breaks only when connected to the debugger. I'm using VS 2012. I've turned off all the relevant 'break on exception' but it still causes the debugger to break and non of my handlers are getting a chance to handle the exception.
If the file is missing I would expect the GetFileAsync method to throw a 'File doesn't exist' exception. Not sure why it keeps throwing the 'Invalid parameter' exception.
This is starting to bother me and I just can't find any known solution to this issue. Anyone have any ideas?
I'm going to try and change the method to not use the task<> code. Instead I'll call the GetFileAsync using 'await'. However I believe 'await' will just cause the calling thread to wait until the GetFileAsync has finished, which kind of defeats the point of asynchronous loading.
I'm wondering if this is a common issue with exception handling when using tasks.
Update:
OK, I've now found the solution:
task<StorageFile^>( location->GetFileAsync(sn)).then([](StorageFile^ openedFile)
{
return FileIO::ReadBufferAsync(openedFile);
}).then([](IBuffer^ readBuffer)
{
// Process file
}).then([](task<void> t)
{
try
{
t.get();
}
catch(Platform::Exception^ e)
{
// Handle error
}
});
It seems there needs to be an extra 'then' condition added to the end of the chain to pick up the exception.
Hey, I'm using a ScriptDebugDelegate to notify me when an exception occurs in the exceptionWasRaised function.
However, I'd like to know how I could ignore the exception, ie. just skip the line of code that'd normally fire an exception.
Thanks
ASH
If you know the line where the exception occurs you could use a try/catch with no code inside the catch block
#try {
//my code that throws exception
} #catch ( NSException *e ) {
}
You can even filter it by using a specific exception type that you want like for CustomException:
#try {
//my code that throws exception
} #catch ( MyCustomException *e ) {
}
What will cause any MyCustomException to be ignored, and all other to be fired.
NOTE: It is important to use that only for testing and debugging proposes as empty catches are always wrong.