4 replaced http://programmers.stackexchange.com/ with https://softwareengineering.stackexchange.com/
source | link

From your applications toplevel point of view, you do want to "crash". If a "nonsense" (your words) exception happens. In a controlled way: Either via an UnhandledExceptionFilter or toplevel catch(Exception).

It's also the easiest option: You don't have to do anything here. Just let the exception propagate.

From comment:

The point is that the code should only crash if the error (whatever nonsense it may describe) compromises the entire code execution.

But it does. From the point of view of that function, if you can't give back a valid directory, the entire calling chain is compromised. It is the job of the caller to decide whether to handle failure of (e.g.) GetCurentExecutableDirectory gracefully.

By example (C#6):

        // Example where the caller decides to handle it: /e.g. a "show exec dir operation"
        try
        {
            string execDir = GetCurentExecutableDirectory();
            Console.WriteLine($"Executable directory is: {execDir}");
        }
        catch(Exception ex) when (AppRules.IsNonCritical(ex))
        {
            Console.WriteLine("Sorry, couldn't determine the executable directory. (You may wish to inspect the logs for further details.)");
            Log(ex);
        }
        // Execution can continue / return normally here

        // ------------------
        // ------------------

        // Example where the caller decides *not* to handle it:
        string execDir = GetCurentExecutableDirectory();
        // Note, we really need this here, 
        // otherwise the rest of the code doesn't make sense ...

You will note that the caller doesn't care what exception caused the failure. The operation it tried to perform failed, and that's it. Log the exception for possible analysis and report back in a user/caller friendly way.

C#6 is nice that way, in that you can just filter out e.g. NullReferenceException in your IsNonCritical filter if you consider that to always be a bug. (CSE are not caught nowadays anyway.)

Side Note: http://programmers.stackexchange.com/q/164256/6559Is catching general exceptions really a bad thing?

From your applications toplevel point of view, you do want to "crash". If a "nonsense" (your words) exception happens. In a controlled way: Either via an UnhandledExceptionFilter or toplevel catch(Exception).

It's also the easiest option: You don't have to do anything here. Just let the exception propagate.

From comment:

The point is that the code should only crash if the error (whatever nonsense it may describe) compromises the entire code execution.

But it does. From the point of view of that function, if you can't give back a valid directory, the entire calling chain is compromised. It is the job of the caller to decide whether to handle failure of (e.g.) GetCurentExecutableDirectory gracefully.

By example (C#6):

        // Example where the caller decides to handle it: /e.g. a "show exec dir operation"
        try
        {
            string execDir = GetCurentExecutableDirectory();
            Console.WriteLine($"Executable directory is: {execDir}");
        }
        catch(Exception ex) when (AppRules.IsNonCritical(ex))
        {
            Console.WriteLine("Sorry, couldn't determine the executable directory. (You may wish to inspect the logs for further details.)");
            Log(ex);
        }
        // Execution can continue / return normally here

        // ------------------
        // ------------------

        // Example where the caller decides *not* to handle it:
        string execDir = GetCurentExecutableDirectory();
        // Note, we really need this here, 
        // otherwise the rest of the code doesn't make sense ...

You will note that the caller doesn't care what exception caused the failure. The operation it tried to perform failed, and that's it. Log the exception for possible analysis and report back in a user/caller friendly way.

C#6 is nice that way, in that you can just filter out e.g. NullReferenceException in your IsNonCritical filter if you consider that to always be a bug. (CSE are not caught nowadays anyway.)

Side Note: http://programmers.stackexchange.com/q/164256/6559

From your applications toplevel point of view, you do want to "crash". If a "nonsense" (your words) exception happens. In a controlled way: Either via an UnhandledExceptionFilter or toplevel catch(Exception).

It's also the easiest option: You don't have to do anything here. Just let the exception propagate.

From comment:

The point is that the code should only crash if the error (whatever nonsense it may describe) compromises the entire code execution.

But it does. From the point of view of that function, if you can't give back a valid directory, the entire calling chain is compromised. It is the job of the caller to decide whether to handle failure of (e.g.) GetCurentExecutableDirectory gracefully.

By example (C#6):

        // Example where the caller decides to handle it: /e.g. a "show exec dir operation"
        try
        {
            string execDir = GetCurentExecutableDirectory();
            Console.WriteLine($"Executable directory is: {execDir}");
        }
        catch(Exception ex) when (AppRules.IsNonCritical(ex))
        {
            Console.WriteLine("Sorry, couldn't determine the executable directory. (You may wish to inspect the logs for further details.)");
            Log(ex);
        }
        // Execution can continue / return normally here

        // ------------------
        // ------------------

        // Example where the caller decides *not* to handle it:
        string execDir = GetCurentExecutableDirectory();
        // Note, we really need this here, 
        // otherwise the rest of the code doesn't make sense ...

You will note that the caller doesn't care what exception caused the failure. The operation it tried to perform failed, and that's it. Log the exception for possible analysis and report back in a user/caller friendly way.

C#6 is nice that way, in that you can just filter out e.g. NullReferenceException in your IsNonCritical filter if you consider that to always be a bug. (CSE are not caught nowadays anyway.)

Side Note: Is catching general exceptions really a bad thing?

3 typo
source | link

From your applications toplevel point of view, you do want to crash"crash". If a "nonsense" (your words) exception happens. IIn a controlled way: Either via an UnhandledExceptionFilter or toplevel catch(Exception).

It's also the easiest option: You don't have to do anything here. Just let the exception propagate.

From comment:

The point is that the code should only crash if the error (whatever nonsense it may describe) compromises the entire code execution.

But it does. From the point of view of that function, if you can't give back a valid directory, the entire calling chain is compromised. It is the job of the caller to decide whether to handle failure of (e.g.) GetCurentExecutableDirectory gracefully.

By example (C#6):

        // Example where the caller decides to handle it: /e.g. a "show exec dir operation"
        try
        {
            string execDir = GetCurentExecutableDirectory();
            Console.WriteLine($"Executable directory is: {execDir}");
        }
        catch(Exception ex) when (AppRules.IsNonCritical(ex))
        {
            Console.WriteLine("Sorry, couldn't determine the executable directory. (You may wish to inspect the logs for further details.)");
            Log(ex);
        }
        // Execution can continue / return normally here

        // ------------------
        // ------------------

        // Example where the caller decides *not* to handle it:
        string execDir = GetCurentExecutableDirectory();
        // Note, we really need this here, 
        // otherwise the rest of the code doesn't make sense ...

You will note that the caller doesn't care what exception caused the failure. The operation it tried to perform failed, and that's it. Log the exception for possible analysis and report back in a user/caller friendly way.

C#6 is nice that way, in that you can just filter out e.g. NullReferenceException in your IsNonCritical filter if you consider that to always be a bug. (CSE are not caught nowadays anyway.)

Side Note: http://programmers.stackexchange.com/q/164256/6559

From your applications toplevel point of view, you do want to crash. If a "nonsense" (your words) exception happens. I a controlled way: Either via an UnhandledExceptionFilter or toplevel catch(Exception).

It's also the easiest option: You don't have to do anything here. Just let the exception propagate.

From comment:

The point is that the code should only crash if the error (whatever nonsense it may describe) compromises the entire code execution.

But it does. From the point of view of that function, if you can't give back a valid directory, the entire calling chain is compromised. It is the job of the caller to decide whether to handle failure of (e.g.) GetCurentExecutableDirectory gracefully.

By example (C#6):

        // Example where the caller decides to handle it: /e.g. a "show exec dir operation"
        try
        {
            string execDir = GetCurentExecutableDirectory();
            Console.WriteLine($"Executable directory is: {execDir}");
        }
        catch(Exception ex) when (AppRules.IsNonCritical(ex))
        {
            Console.WriteLine("Sorry, couldn't determine the executable directory. (You may wish to inspect the logs for further details.)");
            Log(ex);
        }
        // Execution can continue / return normally here

        // ------------------
        // ------------------

        // Example where the caller decides *not* to handle it:
        string execDir = GetCurentExecutableDirectory();
        // Note, we really need this here, 
        // otherwise the rest of the code doesn't make sense ...

You will note that the caller doesn't care what exception caused the failure. The operation it tried to perform failed, and that's it. Log the exception for possible analysis and report back in a user/caller friendly way.

C#6 is nice that way, in that you can just filter out e.g. NullReferenceException in your IsNonCritical filter if you consider that to always be a bug. (CSE are not caught nowadays anyway.)

Side Note: http://programmers.stackexchange.com/q/164256/6559

From your applications toplevel point of view, you do want to "crash". If a "nonsense" (your words) exception happens. In a controlled way: Either via an UnhandledExceptionFilter or toplevel catch(Exception).

It's also the easiest option: You don't have to do anything here. Just let the exception propagate.

From comment:

The point is that the code should only crash if the error (whatever nonsense it may describe) compromises the entire code execution.

But it does. From the point of view of that function, if you can't give back a valid directory, the entire calling chain is compromised. It is the job of the caller to decide whether to handle failure of (e.g.) GetCurentExecutableDirectory gracefully.

By example (C#6):

        // Example where the caller decides to handle it: /e.g. a "show exec dir operation"
        try
        {
            string execDir = GetCurentExecutableDirectory();
            Console.WriteLine($"Executable directory is: {execDir}");
        }
        catch(Exception ex) when (AppRules.IsNonCritical(ex))
        {
            Console.WriteLine("Sorry, couldn't determine the executable directory. (You may wish to inspect the logs for further details.)");
            Log(ex);
        }
        // Execution can continue / return normally here

        // ------------------
        // ------------------

        // Example where the caller decides *not* to handle it:
        string execDir = GetCurentExecutableDirectory();
        // Note, we really need this here, 
        // otherwise the rest of the code doesn't make sense ...

You will note that the caller doesn't care what exception caused the failure. The operation it tried to perform failed, and that's it. Log the exception for possible analysis and report back in a user/caller friendly way.

C#6 is nice that way, in that you can just filter out e.g. NullReferenceException in your IsNonCritical filter if you consider that to always be a bug. (CSE are not caught nowadays anyway.)

Side Note: http://programmers.stackexchange.com/q/164256/6559

2 typo
source | link

From your applications toplevel point of view, you do want to crash. If a "nonsense" (your words) exception happens. I a controlled way: Either via an UnhandledExceptionFilter or toplevel catch(Exception).

It's also the easiest option: You don't have to do anything here. Just let the exception propagate.

From comment:

The point is that the code should only crash if the error (whatever nonsense it may describe) compromises the entire code execution.

But it does. From the point of view of that function, if you can't give back a valid directory, the entire calling chain is compromised. It is the job of the caller to decide whether to handle failure of (e.g.) GetCurentExecutableDirectory gracefully.

By example (C#6):

        // Example where the caller decides to handle it: /e.g. a "show exec dir operation"
        try
        {
            string execDir = GetCurentExecutableDirectory();
            Console.WriteLine($"Executable directory is: {execDir}");
        }
        catch(Exception ex) when (AppRules.IsNonCritical(ex))
        {
            Console.WriteLine("Sorry, couldn't determine the executable directory. (You may wish to inspect the logs for further details.)");
            Log(ex);
        }
        // Execution can continue / return normally here

        // ------------------
        // ------------------

        // Example where the calledcaller decides *not* to handle it:
        string execDir = GetCurentExecutableDirectory();
        // Note, we really need this here, 
        // otherwise the rest of the code doesn't make sense ...

You will note that the caller doesn't care what exception caused the failure. The operation it tried to perform failed, and that's it. Log the exception for possible analysis and report back in a user/caller friendly way.

C#6 is nice that way, in that you can just filter out e.g. NullReferenceException in your IsNonCritical filter if you consider that to always be a bug. (CSE are not caught nowadays anyway.)

Side Note: http://programmers.stackexchange.com/q/164256/6559

From your applications toplevel point of view, you do want to crash. If a "nonsense" (your words) exception happens. I a controlled way: Either via an UnhandledExceptionFilter or toplevel catch(Exception).

It's also the easiest option: You don't have to do anything here. Just let the exception propagate.

From comment:

The point is that the code should only crash if the error (whatever nonsense it may describe) compromises the entire code execution.

But it does. From the point of view of that function, if you can't give back a valid directory, the entire calling chain is compromised. It is the job of the caller to decide whether to handle failure of (e.g.) GetCurentExecutableDirectory gracefully.

By example (C#6):

        // Example where the caller decides to handle it: /e.g. a "show exec dir operation"
        try
        {
            string execDir = GetCurentExecutableDirectory();
            Console.WriteLine($"Executable directory is: {execDir}");
        }
        catch(Exception ex) when (AppRules.IsNonCritical(ex))
        {
            Console.WriteLine("Sorry, couldn't determine the executable directory. (You may wish to inspect the logs for further details.)");
            Log(ex);
        }
        // Execution can continue / return normally here

        // ------------------
        // ------------------

        // Example where the called decides *not* to handle it:
        string execDir = GetCurentExecutableDirectory();
        // Note, we really need this here, 
        // otherwise the rest of the code doesn't make sense ...

You will note that the caller doesn't care what exception caused the failure. The operation it tried to perform failed, and that's it. Log the exception for possible analysis and report back in a user/caller friendly way.

C#6 is nice that way, in that you can just filter out e.g. NullReferenceException in your IsNonCritical filter if you consider that to always be a bug. (CSE are not caught nowadays anyway.)

Side Note: http://programmers.stackexchange.com/q/164256/6559

From your applications toplevel point of view, you do want to crash. If a "nonsense" (your words) exception happens. I a controlled way: Either via an UnhandledExceptionFilter or toplevel catch(Exception).

It's also the easiest option: You don't have to do anything here. Just let the exception propagate.

From comment:

The point is that the code should only crash if the error (whatever nonsense it may describe) compromises the entire code execution.

But it does. From the point of view of that function, if you can't give back a valid directory, the entire calling chain is compromised. It is the job of the caller to decide whether to handle failure of (e.g.) GetCurentExecutableDirectory gracefully.

By example (C#6):

        // Example where the caller decides to handle it: /e.g. a "show exec dir operation"
        try
        {
            string execDir = GetCurentExecutableDirectory();
            Console.WriteLine($"Executable directory is: {execDir}");
        }
        catch(Exception ex) when (AppRules.IsNonCritical(ex))
        {
            Console.WriteLine("Sorry, couldn't determine the executable directory. (You may wish to inspect the logs for further details.)");
            Log(ex);
        }
        // Execution can continue / return normally here

        // ------------------
        // ------------------

        // Example where the caller decides *not* to handle it:
        string execDir = GetCurentExecutableDirectory();
        // Note, we really need this here, 
        // otherwise the rest of the code doesn't make sense ...

You will note that the caller doesn't care what exception caused the failure. The operation it tried to perform failed, and that's it. Log the exception for possible analysis and report back in a user/caller friendly way.

C#6 is nice that way, in that you can just filter out e.g. NullReferenceException in your IsNonCritical filter if you consider that to always be a bug. (CSE are not caught nowadays anyway.)

Side Note: http://programmers.stackexchange.com/q/164256/6559

1
source | link