Is throwing exceptions in Debug mode a bad idea? [closed]

Question

Closed. This question needs to be more focused. It is not currently accepting answers.

---

Want to improve this question? Update the question so it focuses on one problem only by editing this post.

Closed 1 year ago.

Improve this question

I am working in an iOS project which have two schemes enabled from configurations,

• Release
• Debug

As you know Debug scheme is used for developers while developing features and testing etc. However, Release scheme is used for generating official final artefact to upload in App Store. Currently my application quality is not good and many exceptions are not properly handled by developers (most of them are ignored). In current codebase most of the methods are developed in such a way that when exceptions happens they are catched and printed in log. Let's say here is a pseudocode,

func doSomething() {
    do {
        //code that might generate exception
    } catch let error {
        print("Error: \(error)")
    }
} 

However, I feel many exceptions should be thrown in development phase and developers should invest more time to analyse and fix them. For that reason I want to log exceptions only in Release mode but not in Debug mode. Let’s say my intention is to refactor the above similar code as below,

func doSomething() throws  {

    do {
        //code that might generate exception e
    } catch let error {

        #if Release
            print("Error: \(error)")
        #else Debug
            throw error
        #endif
    }
} 

Is there is any other issues might arise for this approach? Is it a bad idea anyway?

Answer 1

There is no hard and fast rules how to handle errors. When an operation could (theoretically) produce an error, you need to look at the situation, each situation individually, and decide how to cope with it.

Case 1: Errors that you are convinced cannot happen. Check for them, and in a debug version have an assertion that will stop execution in the debugger, so you can examine why the error (that you were convinced couldn't happen) did happen, and what to do about it, and change your code.

Case 2: Errors that you can fix. Add code to fix them.

Case 3: Errors that the user can fix, possibly by talking to their admin, sometimes by trying again: Find the best advice to the user, and show an alert to the user advising them how to fix. Change your code so it doesn't cause damage in this case.

Case 4: Errors that you have no idea how to handle. You say "if this ever goes wrong, we are just ****ed.". Decide whether you want to handle them like case 1, or you might want to change your code so that shuts down your app safely.