This project is read-only.

too generic error messages

Sep 11, 2009 at 10:33 PM


when extracting a zip DotNetZip returned with a Ionic.Zip.ZipException "Cannot extract"

     ex.StackTrace    "   at Ionic.Zip.ZipEntry.InternalExtract(String baseDir, Stream outstream, String password)
   at Ionic.Zip.ZipEntry.Extract(String baseDirectory, ExtractExistingFileAction extractExistingFile)
   at FileAccess.MyUnZip.unzip(String sourcePath, String destPath, Boolean flattenDirs, List`1 list, Int64 fileSize) in C:\Documents and Settings\ye456c\My Documents\SNETPC\SNETPC2006\FileAccess\MyZip.vb:line 436"    String


i extracted with 7-Zip without an issue, but it wasn't until i tried to delete the directory that i realized that the stupid folder name was too large for the OS (XP sp2) and now i cannot get rid of it. pat on the back for DotNetZip for catching this error before that happened, but the message "Cannot extract" only made me panic like something was wrong with the library.

is there a list of the known exception messages so i can convert them into more useful messages for the users? i will likely have to do that conversion anyway to match the old error messages because MY users don't like changes much. when they call the helpline, i need at least some way of figuring out what happened. i already tried searching the doc for these messages without any luck.


Sep 11, 2009 at 11:12 PM

No, I don't have a list of Exceptions.

Is there something wrong with this exception message?   If it's not appropriate or clear enough I can change it.

There will be a nested exception message, that provides more information.


Sep 12, 2009 at 1:33 AM

i looked and the inner exception is much better.

     ex.InnerException.Message    "The specified path, file name, or both are too long. The fully qualified file name must be less than 260 characters, and the directory name must be less than 248 characters."    String


why not return the source exception message or a modified version of it? the way i usually organize my exceptions is by the exception types. returning a root level exception defeats the purpose of having multiple catch blocks.  if i know that a specific error has a particular exception, i can code a custom response to it.

im going to have to write code to iterate though the nested exceptions having to be really careful not to allow them to create their own nullpointerexcetions.

im also a java programmer, so forgive me for liking my exceptions so much :)

Sep 12, 2009 at 1:43 AM

I think you're right.  The exception should not be nested.

I'll change that.