Home>

I am creating a process to decompress the compressed file with C # and refer to the csv inside.
What I want to do is very simple, and it looks like the following.

try
{
  Decompression process (compressed file name)
}
catch (Exception e)
{
  Console.WriteLine ("Decompression failed:" + (compressed file name));
  if (File.Exists (csv file name) File.Delete (csv file name);
}

I thought I could get it with e.source, but unexpectedly the string "System" (?) Is returned.
Although an exception has occurred, a 0-byte csv file is created, so if you read it, an error will occur.
Therefore, it cannot be used for subsequent processing.
However, it is still an exception that occurred in the decompression process, so I want to perform error processing (csv is discarded) in it.

Currently, a variable is prepared before try-catch, the compressed file name is set with try, and it is referenced with catch.
The code is not super cool.

Is there a way to pass the compressed file name only by the exception mechanism without using variables?

c#
  • Answer # 1

    Currently, it is a super cool code that prepares a variable before try ~ catch, sets the compressed file name with try and refers to it with catch.

    The place where Exception is caught is not cool, but other than that, I think that it is not so cool as to get "super".

    There is a specific exception that can occur in the "decompression process (compressed file name)", which may be described in the documentation of the library that performs the decompression process. If so, why not just catch it and process it?

    You should stop catching Exceptions anyway. You end up not catching exceptions that are unpredictable or predictable but unresponsive (eg server down). Then, the user may continue to work and corrupt important data or worsen the situation. Instead, it seems better to let the runtime pick up the exception and stop the application.

    It seems that you can no longer catch corrupted state exceptions from .NET 4, but see the following article for "still not good to use Catch (Exception e)".

    Handle corruption state exceptions
    https://docs.microsoft.com/ja-jp/archive/msdn-magazine/2009/february/clr-inside-out-handling-corrupted-state-exceptions

  • Answer # 2

    If the decompression library is throwing its own Exception, you may be able to get a little more detailed information by examining the inside of the Exception. You may want to look at other properties in the debugger, or look at InnerException.

    I thought I could get it with e.source, but unexpectedly the string "System" (?) Is returned.
    (Omitted)
    Currently, a variable is prepared before try-catch, the compressed file name is set with try, and it is referenced with catch.
    The code is not super cool.

    If you want to add information that is not in the original exception, I feel that it can't be helped. At the time of catch, you may throw your own exception with more properties of the unzipped filename. (This is the method answered by y_waiwai)

  • Answer # 3

    >Currently, it is a super cool code that prepares a variable before try ~ catch, sets the compressed file name with try and refers to it with catch.

    Isn't that because the functions aren't divided well?
    For example, since the source is not presented, there are some predictions, but isn't it because you are thinking of processing the target compression file name determination logic and compression processing in the same function?

    For example, if the configuration is 1 CSV for 1 compressed file, the necessary information will be the compressed file name if you focus only on the decompression processing function as shown below, so pass the compressed file name to the target procedure.

    * Regarding inheritance of exception class, I think that it is common to prepare other constructors, but I omit it.

      private void Test () {
            try {
                var csvFilePath = Unzip ("hoge.zip");
            } catch (UnzipException e) {
                Console.WriteLine ("Unzip failed:" + e.SourceFilePath);
            }
        }
        public class UnzipException: Exception {
            public string SourceFilePath {get;}
            public UnzipException (string sourceFilePath, Exception innerException)
                : base ($"\" {sourceFilePath} \ "decompression error", innerException) {
                this.SourceFilePath = sourceFilePath;
            }
        }
        public static string Unzip (string targetFilePath) {
            var outputCsvFilePath = CSV output file name;try {
                Decompression process (targetFilePath);
                return outputCsvFilePath;
            } catch (Exception e) {
                if (File.Exists (outputCsvFilePath)) {
                    File.Delete (outputCsvFilePath);
                }
                throw new UnzipException (targetFilePath, e);
            }
        }
    }

    Supplement:
    I don't think you should receive the catch part in the Unzip procedure as an Exception, as others have said.
    I think this example is good at catching the types of exceptions that can be expected.

  • Answer # 4

    If you detect that the decompression failed during the decompression process,
    Let's throw an exception that sets a message with a file name attached.
    Then you will be able to read the file name from there