This project is read-only.


SharpBox should throw exception to get detailed error information


SharpBox should throw exceptions in the case of an error so that an application can show up detailed information about the source and the error conditions
Closed Oct 14, 2010 at 6:22 PM by dei79
Added several exceptions with changeset:


scode wrote Oct 9, 2010 at 3:37 AM

Good job! I just have a few comments.

1) public SharpBoxProviderException(int ErrorCode, String message
I strongly feel that the errorCode should be an enum rather than int.

2) int ErrorCode -> int errorCode

3) SharpBoxException : SystemException -> should be inherited from the Exception class instead. Long ago Microsoft was preaching that aplication exceptions should be inherited from the ApplicationException class, but later they changed the design guideline and now the recommended way is to inherit custom exceptions from the Exception class.

4) Personally, I’m not seeing any benefit in the exceptions delivered from the SharpBoxException. Anyone using SharpBox would be catching the SharpBoxException and analyze the errorCode.
But it’s just me, may be other guys would prefer to catch specific exceptions.

5) How about keeping the error messages from the SharpBoxErrorCodes in a resource file? This way those messages could be easily localized.
And one more thing…there is no need for the class SharpBoxErrorCodes. It should be an enum.


dei79 wrote Oct 9, 2010 at 12:10 PM


I removed the derived exceptions from the library, we have only the SharpBoxException for error handling. Additionally I moved the errorcodes to an enum and I using Exception as base class (good points).

Adding the error messages from ressource will be implemented soon (this weekend), it's a great idea.


wrote Oct 10, 2010 at 12:50 PM

dei79 wrote Oct 10, 2010 at 12:57 PM


I added some code for resource based error message handling :-)


scode wrote Oct 11, 2010 at 2:46 AM

that's looks great! Are you planning to release 1.0.2 any time soon?

Just one comment
enum nSharpBoxErrorCodes - why prefix it with the n? It kinda goes against all the C# naming conventions.

dei79 wrote Oct 11, 2010 at 2:54 PM


the realease of 1.0.2 is planned for the end of this month. Cross the fingers that all bugs an requests will be fixed in this time :-)


wrote Oct 14, 2010 at 6:22 PM

wrote Feb 22, 2013 at 1:06 AM

wrote May 16, 2013 at 12:28 PM