I wonder if having a variant of ‘throws’ might allow this... ‘throws!’ would act exactly like throws, but it could be called without ‘try’ (resulting in a crash if it tries to throw). Basically, any statement calling a function/operation with throws! would have the equivalent of an implicit ‘try!' unless there is an actual ‘try’.
It would allow the following (assuming + is marked ‘throws!’):
let x = 2 + 3 // No crash, No exception
let y = try Int.max + 1 // Exception, but no crash
let z = Int.max + 1 // Crash!
let w = try? Int.max + 1 // nil
Similarly, the thread mentions the desire for a throwing forced unwrap operator, and I think this allows that as well. Assuming the force unwrap operator is marked 'throws!’:
let x:Int? = nil
let y = try x! // Exception, but no crash
let z = x! // Crash!
Anyway, this is all of the top of my head, so I am sure there is some issue I am missing. I am not entirely sure that this would allow more good than evil overall, but I do like that the ! in ‘throws!’ signifies danger. In the cases above, it is being used to take something which already crashes now, and allow the programmer to catch an exception instead of that crash if they think to look for it.
This seems like reasonable feature for me. Combined with throwing subscripts (proposed in another thread), we could translate that into bounds checking as well:
let array = [1, 2, 3]
let fifth = array[5] // traps
let fifth = try? array[5] // nil
However, I'm still trying to find a use case for catching such errors. Imagine you're making a GUI app (e.g. for iOS), and then write the following code:
do {
let fifth = try array[5]
} catch BoundsError {
// ???
}
or
let sum: Int = Int.max // assuming it has the max value by accident
do {
sum += 1
} catch ArithmeticError {
// ???
}
What would you do in the catch clause?
Pozdrawiam – Regards,
Adrian Kashivskyy
···
Wiadomość napisana przez Jonathan Hull via swift-evolution <swift-evolution@swift.org> w dniu 07.12.2015, o godz. 10:29:
For context, I just read this thread (that happened before I joined) which discusses the idea of having a variant of arithmetic which can throw on overflow: [swift-evolution] Failable arithmetic
I wonder if having a variant of ‘throws’ might allow this... ‘throws!’ would act exactly like throws, but it could be called without ‘try’ (resulting in a crash if it tries to throw). Basically, any statement calling a function/operation with throws! would have the equivalent of an implicit ‘try!' unless there is an actual ‘try’.
It would allow the following (assuming + is marked ‘throws!’):
let x = 2 + 3 // No crash, No exception
let y = try Int.max + 1 // Exception, but no crash
let z = Int.max + 1 // Crash!
let w = try? Int.max + 1 // nil
Similarly, the thread mentions the desire for a throwing forced unwrap operator, and I think this allows that as well. Assuming the force unwrap operator is marked 'throws!’:
let x:Int? = nil
let y = try x! // Exception, but no crash
let z = x! // Crash!
Anyway, this is all of the top of my head, so I am sure there is some issue I am missing. I am not entirely sure that this would allow more good than evil overall, but I do like that the ! in ‘throws!’ signifies danger. In the cases above, it is being used to take something which already crashes now, and allow the programmer to catch an exception instead of that crash if they think to look for it.
You would display an error (in different ways depending on the UI & error), which is much nicer than crashing on the user. For example, in an app like Numbers, you would display a little warning icon in the cell instead of crashing.
···
On Dec 7, 2015, at 2:12 AM, Adrian Kashivskyy <adrian.kashivskyy@me.com> wrote:
This seems like reasonable feature for me. Combined with throwing subscripts (proposed in another thread), we could translate that into bounds checking as well:
let array = [1, 2, 3]
let fifth = array[5] // traps
let fifth = try? array[5] // nil
However, I'm still trying to find a use case for catching such errors. Imagine you're making a GUI app (e.g. for iOS), and then write the following code:
do {
let fifth = try array[5]
} catch BoundsError {
// ???
}
or
let sum: Int = Int.max // assuming it has the max value by accident
do {
sum += 1
} catch ArithmeticError {
// ???
}
What would you do in the catch clause?
Pozdrawiam – Regards,
Adrian Kashivskyy
Wiadomość napisana przez Jonathan Hull via swift-evolution <swift-evolution@swift.org <mailto:swift-evolution@swift.org>> w dniu 07.12.2015, o godz. 10:29:
For context, I just read this thread (that happened before I joined) which discusses the idea of having a variant of arithmetic which can throw on overflow: [swift-evolution] Failable arithmetic
I wonder if having a variant of ‘throws’ might allow this... ‘throws!’ would act exactly like throws, but it could be called without ‘try’ (resulting in a crash if it tries to throw). Basically, any statement calling a function/operation with throws! would have the equivalent of an implicit ‘try!' unless there is an actual ‘try’.
It would allow the following (assuming + is marked ‘throws!’):
let x = 2 + 3 // No crash, No exception
let y = try Int.max + 1 // Exception, but no crash
let z = Int.max + 1 // Crash!
let w = try? Int.max + 1 // nil
Similarly, the thread mentions the desire for a throwing forced unwrap operator, and I think this allows that as well. Assuming the force unwrap operator is marked 'throws!’:
let x:Int? = nil
let y = try x! // Exception, but no crash
let z = x! // Crash!
Anyway, this is all of the top of my head, so I am sure there is some issue I am missing. I am not entirely sure that this would allow more good than evil overall, but I do like that the ! in ‘throws!’ signifies danger. In the cases above, it is being used to take something which already crashes now, and allow the programmer to catch an exception instead of that crash if they think to look for it.
There’s a common scenario where there are multiple algorithms that might be used to perform a computation:
do {
// fast algorithm that is usually correct by may overflow on rare inputs
} catch ArithmeticError {
// slow algorithm that can give correct result no matter what
}
Note that it’s often *faster* to structure the computation this way than it is to try to inspect the inputs to ascertain whether or not the slow algorithm needs to be used before doing the work.
– Steve
···
On Dec 7, 2015, at 5:12 AM, Adrian Kashivskyy via swift-evolution <swift-evolution@swift.org> wrote:
This seems like reasonable feature for me. Combined with throwing subscripts (proposed in another thread), we could translate that into bounds checking as well:
let array = [1, 2, 3]
let fifth = array[5] // traps
let fifth = try? array[5] // nil
However, I'm still trying to find a use case for catching such errors. Imagine you're making a GUI app (e.g. for iOS), and then write the following code:
do {
let fifth = try array[5]
} catch BoundsError {
// ???
}
or
let sum: Int = Int.max // assuming it has the max value by accident