Explore and reinforce your understanding of Swift error handling, focusing on try, catch, throw, and related keywords. This quiz covers practical scenarios and key concepts essential for beginners learning to manage errors effectively in Swift programming.
Which keyword is used in Swift to indicate that an error has occurred within a function or method?
Explanation: The 'throw' keyword is used within a function or method to signal that an error has occurred. 'throws' is used in the function declaration to indicate that the function can throw errors, but not to actually throw one. 'catch' is used for handling errors, and 'try' is used when calling a throwing function. Only 'throw' can actually signal an error occurrence.
What annotation must be added to a Swift function's declaration to allow it to throw errors?
Explanation: 'throws' is placed after the parameter list in a function declaration to allow the function to throw errors. The word 'throw' is used inside the function, not in its declaration. 'catch' and 'error' are not valid annotations for this purpose. Passing 'throws' signals to the caller that the function may produce an error.
When calling a function that can throw an error in Swift, what keyword must be used before the function call?
Explanation: The 'try' keyword is required before calling a function that can throw an error, indicating the operation might fail and needs proper handling. 'throw' is for generating errors, not calling. 'catch' is for error handling after a thrown error, and 'throwing' is not a valid Swift keyword. Only 'try' initiates the throwing call.
Which code structure is used in Swift to handle errors thrown by functions that use 'throw'?
Explanation: Swift uses 'do-catch' blocks to catch and handle errors thrown by functions. 'if-else' and 'guard-else' are general control flow statements but do not handle thrown errors. 'repeat-while' is used for looping and is unrelated to error handling. Only 'do-catch' is tailored for this purpose.
What does using the 'try?' keyword before a throwing function return if an error is thrown?
Explanation: Using 'try?' attempts to call a throwing function and automatically returns nil if an error occurs, converting the result to an optional. It does not return false or 0, and it does not propagate an uncaught error. This helps safely handle errors in a concise way.
What happens if you use 'try!' with a throwing function that actually throws an error?
Explanation: 'try!' forcefully executes a throwing function and assumes no error will occur; if one is thrown, the program crashes. The error is not ignored or caught automatically, and Swift does not simply emit a warning. It is a risky way to handle error-prone functions.
What must custom error types in Swift conform to in order to be thrown?
Explanation: Custom error types in Swift must conform to the Error protocol to be used with throw. 'Throwable', 'Exception', and 'ThrowType' are not recognized interfaces or keywords in Swift. The Error protocol ensures that conforming types can be thrown and caught properly.
Where should you place code that may throw an error in Swift to handle the possible error properly?
Explanation: Code that may throw an error should be placed inside the 'do' block of a 'do-catch' statement to catch and handle errors effectively. 'repeat' blocks and 'guard' or 'if let' statements are not designed for direct error handling. Only the 'do-catch' structure provides the required mechanism.
Which part of the 'do-catch' structure allows you to handle specific error types differently?
Explanation: Swift's 'catch' clauses inside a 'do-catch' block can use pattern matching to respond to different error types or values. The 'throw' statement only generates errors but does not handle them, and function return types or 'try' do not relate to customizing error handling. Pattern matching in 'catch' provides flexibility.
Why might a developer use 'try?' instead of 'try' or 'try!' when calling a throwing function?
Explanation: 'try?' is used when a developer prefers to get an optional result (nil on error) and wants to avoid explicit error handling code. It does not guarantee error absence, nor does it force a non-optional return or automatically rethrow errors. This approach is for cases where errors can be safely ignored.