Dec-17-2019, 05:43 AM
(This post was last modified: Dec-17-2019, 05:43 AM by Clunk_Head.)
(Dec-16-2019, 11:08 PM)Skaperen Wrote: i have tried nothing, yet. unless i can come up with a good test the covers all possible cases, i don't bother to waste my time trying it. for this, my concern is whether a direct raise might, for some exceptions, be handled different because it is in a try clause. a test for that would need to try every possible exception. it is impractical to do a test like that, so i did not try. but if you have a way to do it, i am interested. a file listing every possible exception might be usable as i could build a code sequence from that
i already know how to raise an exception and how to handle one. i do not know if anything different is done in an explicit raise inside a try clause that, while trying to optimize certain behavior, might end up making certain exceptions behave slightly different.
Sorry that you don't want to waste your time. I wouldn't expect anyone else to, either, given that it's your code.
That aside, There is no difference in handling a raised exception regardless of where it is raised. You should be able to determine every type of exception that your code can possible throw by examining each action that you take. For instance casting data types can throw a TypeError, the use of lists can produce an IndexOutOfBoundsException, Using dictionaries can produce a KeyError. However, you should not need to go through every possible type of exception.
Once you have accounted for each type of exception make an except to deal with it. Another user in the thread correctly suggested using a more exotic error type, which makes a lot of sense.
Give it a shot, it's not too difficult.
When you've got something post it if it doesn't work the way that you expect. I'm sure many here will help fix errors once there is code on which to work.