-3

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?

  • 2
    Why did you take a deleted question of yours and rewrite it as a completely new, unrelated question rather than posting a new question? – 1201ProgramAlarm May 19 at 17:26
  • @1201ProgramAlarm i am banned from posting new questions from that site. Thats the only option i have left. – Sazzad Hissain Khan May 19 at 20:12
  • @1201ProgramAlarm please find the evidence of my struggle here softwareengineering.meta.stackexchange.com/q/8939/208831 – Sazzad Hissain Khan May 19 at 21:15
  • @RobertHarvey in which sense this post is too broad? This is a specific design pattern problem where I have even tried to put code level example. If these is too broad there are thousands of posts in this site with many up votes which you moderators guys didn't think to hold at all (i.e softwareengineering.stackexchange.com/revisions/164256/1). – Sazzad Hissain Khan May 20 at 6:18
  • Design pattern are defined for an identified problem. What you present as a design pattern is an just an idea that you might want to propagate to all your codebase whatever the specific piece of code should do as such, it is too broad. This idea might only be good if you have to rely on a unreliable (say for instance legacy) piece of software. Normally your debug code should works exactly the same as production code. – Walfrat May 20 at 14:42
2

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.

Not the answer you're looking for? Browse other questions tagged or ask your own question.