12

I have created a custom exception class as below 

namespace testingEXception
{
    public class CustomException : Exception
    {            
        public CustomException()
        {
        }
        public CustomException(string message)
            : base(message)
        {
        }

        public CustomException(string message, Exception innerException)
            : base(message, innerException)
        {

        }
    }
}

I am throwing an exception from a different project in the same solution like this

namespace ConsoleApplication1
{
    public class testClass
    {
        public void compare()
        {
            if (1 > 0)
            {
                throw new CustomException("Invalid Code");
            }
        }
    }
}

and catching it like this

    namespace testingEXception
{
    class Program
    {
        static void Main(string[] args)
        {
            try
            {
                testClass obj = new testClass();
                obj.compare();

            }
            catch (testingEXception.CustomException ex)
            {
                //throw;
            }
            catch (Exception ex)
            {
               // throw new CustomException(ex.Message);
            }

            Console.ReadKey();
        }
    }
}

The problem is, the exception is not getting caught by the first catch, but instead getting caught by the second catch, over though the type of exception shows CustomException.

jessegavin
  • 74,067
  • 28
  • 136
  • 164
Hataf Moin
  • 161
  • 1
  • 2
  • 9
  • what you are showing is correct and should work. SO either you are not doing what you think you are doing, or whats happening is not what you think is happening. Check that you dont have several CustomException in different namespaces (in VS do 'Go to definition' on the throw and the catch version of CustomeException) – pm100 Aug 14 '13 at 17:01
  • 3
    With the "throw" in the catch(CustomException) it's going to re-thrown and be caught by catch(Exception). Is that what you're seeing? – Peter Ritchie Aug 14 '13 at 17:06
  • @PeterRitchie on debugging, the debugger is not stopping on first catch,instead stop on the second catch. – Hataf Moin Aug 14 '13 at 17:17
  • Add `Trace.WriteLine("CustomException");` before the first `throw;`. You would get a compile error if `catch(CustomException)` was ignored because of `catch(Exception)` – Peter Ritchie Aug 14 '13 at 17:44
  • @PeterRitchie i have tried Trace.WriteLine("CustomException"); It is compiling perfectly. – Hataf Moin Aug 15 '13 at 07:10
  • @HatafMoin You missed my point, *if* `CustomException` was really ignored the compiler would have given you an error with the existing code. Adding the `Trace.WriteLine` was to show that it is being caught. – Peter Ritchie Aug 15 '13 at 13:39
  • @PeterRitchie a throw from one catch block will never get caught in another catch block as you indicate. – brader24 Aug 15 '13 at 13:58
  • @PeterRitchie I found out that the issue is producing when I am throwing exception from one project and catching in other project in the same solution – Hataf Moin Aug 16 '13 at 14:37
  • 1
    @HatafMoin So, the code you posted does not reproduce the problem, please post code that allows someone to reproduce the problem. It also sounds that CustomException is *not* public. – Peter Ritchie Aug 16 '13 at 14:42
  • I know this is old, but I do not think anyone has quite defined what to do in this situation. First off, you cannot cross from one assembly to another with a custom exception (see @PeterRichie below for technical on this), The way you can accomplish this is by creating your custom exception, and place it in the inner exception of Exception. this will cross the assembly bounds and quit nicely, you can add any information you need in your custom exception. I hope this helps someone. – Lawrence Thurman Jun 08 '17 at 03:41

1 Answers1

2

You need to provide more detail, the following code outputs "CustomException":

try
{
    throw new CustomException("Invalid code.");
}
catch (CustomException ex)
{
    System.Diagnostics.Trace.WriteLine("CustomException");
    throw;
}
catch (Exception ex)
{
    throw;
}

With the following class:

public class CustomException : Exception
{
    public CustomException()
    {
    }
    public CustomException(string message)
        : base(message)
    {
    }

    public CustomException(string message, Exception innerException)
        : base(message, innerException)
    {

    }
}

Update:

With regard to optimizations and optimizing away a throw: this cannot happen because any particular block of code cannot know whether a caller higher up in the stack could have code to catch CustomException. Throwing an exception is a visible side-effect and there are various guarantees in the CLI to ensure those visible side-effects remain visible.

In addition, try, catch and finally blocks are "protected regions" in CLI-speak. These regions are special in that the operations within the region with "visible" side-effects cannot have their visible side-effects re-ordered. For some more detail, see http://lynk.at/qH8SHk and http://lynk.at/pJcg98

Peter Ritchie
  • 35,463
  • 9
  • 80
  • 98
  • The only thing I can think of is that if both blocks just rethrow the exception and nothing else, then, depending on the optimizations the compiler uses, it may optimize out the first catch block. I tried it though in a test app and it didn't happen for me. – brader24 Aug 15 '13 at 14:03
  • Compiler does almost now optimizations within try or finally blocks. It certainly can't optimize away a throw or a catch. – Peter Ritchie Aug 15 '13 at 14:08
  • I don't think it is. I suspect there is something else going on and more detail is needed. Maybe like someone else mentioned, there is a type conflict or something. I only indicate that the result of the two catch blocks as he wrote them is the same if all that either does is to rethrow the exception so if the compiler were smart enough it MIGHT be possible for it to optimize out the first catch. The behavior wouldn't change. Not saying it does or would. – brader24 Aug 15 '13 at 14:13
  • It can't optimize the first catch, there are CLI guarantees like side-effects and exceptions generated by a thread are visible in the order specified by the CIL (ecma 335) so, it can't optimize away a throw. This is mostly due to the fact that the code cannot know if code higher up in the stack could catch CustomException and therefore cannot simply stop throwing CustomException. – Peter Ritchie Aug 15 '13 at 14:47