Assertion on Type conversion

[arbabi]

Hello,

I have problem that might be easily answered.

Consider the following scenario:

CustomType aType = null;

try
{
aType = CustomType.Parse(someString);
}
catch
{
throw new ApplicationException("wrong custom type!");
}
//continue using the aType

Now here is my question:

I want to get rid of the Try-Catch statement, how can I replace the
above statements with Debug.Assert? is it possible at all?

thanks,

[Dave]

Debug.Assert would have to be called in the Parse() method. It is only useful in DEBUG builds, so it's not recommended for runtime
parameter checking for non-debug builds (live deployments, etc.)

Instead, I would recommend testing someString before attempting to parse it and throwing an ArgumentException when it can't be
parsed. This will prevent invalid use of the Parse() method at runtime in any build configuration.

Is there a reason you want to do this that someone may help you with?

--
Dave Sexton
dave@www..jwaonline..com
-----------------------------------------------------------------------
<ar****@yahoo.com> wrote in message news:11**********************@l41g2000cwc.googlegr oups.com...

Hello,

I have problem that might be easily answered.

Consider the following scenario:

CustomType aType = null;

try
{
aType = CustomType.Parse(someString);
}
catch
{
throw new ApplicationException("wrong custom type!");
}
//continue using the aType

Now here is my question:

I want to get rid of the Try-Catch statement, how can I replace the
above statements with Debug.Assert? is it possible at all?

thanks,

[arbabi]

Dave, thanks for the reply.

1- I didn't explain my problem clearly.
2- As you suggested CustomType.Parse has its own exception
3- I am *expecting* that conversion of "someString" to CustomType is
always true.

*post-condition assertion in Design-by-Contract is what I am looking
for*
As you already mentioned all the assertions are checked during the
debug mode, so I was looking for some kind of code that help me to
eliminate the try-catch statement by using an Assert statement.

BTW, if I could kust use "as" statement I could accomplish this task.

[Dave]

You can't override "as" functionality, but you may override the explicit cast operator on your type:

public static explicit operator CustomType (string typeAsString)
{
// Todo: parse typeAsString into CustomType
}

I'm still not sure what you are trying to accomplish, but this may help, I guess. By the way, be careful using operator overloads
since languages like VB.NET will not support them. They will have to call the implementation-hidden method like op_Explicit, etc.

--
Dave Sexton
dave@www..jwaonline..com
-----------------------------------------------------------------------
<ar****@yahoo.com> wrote in message news:11**********************@f14g2000cwb.googlegr oups.com...

Dave, thanks for the reply.

1- I didn't explain my problem clearly.
2- As you suggested CustomType.Parse has its own exception
3- I am *expecting* that conversion of "someString" to CustomType is
always true.

*post-condition assertion in Design-by-Contract is what I am looking
for*
As you already mentioned all the assertions are checked during the
debug mode, so I was looking for some kind of code that help me to
eliminate the try-catch statement by using an Assert statement.

BTW, if I could kust use "as" statement I could accomplish this task.

[arbabi]

I already have that, but I still need to use it in try-catch, don't I?

This is what I wanted to acheive:

http://c2.com/cgi/wiki?DesignByContract

But I can't explain it because I think I haven't grasp it properly as
well. I know that much that it tries to separate the implementation
from what we are expectnig to see on the output, the main reason for
doing that is to catch the errors before hand. As it is suggested in
the above URL I believe XP Unit-Testing can replace it.

[Dave]

The author's claim, from what I undestand it to be, is that methods should not require Try..Catch blocks to check conditional
requirements known to the calling method. I very much disagree.

The author states that "if a method has specified some pre-condition then the failure of that condition is the responsibility of the
client of the method". In programming terms, from my understanding of the author's statement, this means that a methods failure
depends on the caller's ability to check for conditions, and assure them to be correct, prior to the calling of the method.

This is the sole purpose of documentation :)

The author did not explain what actions the caller should take if it cannot satisfy these conditions. It seems to be assumed that
the caller will be able to gracefully handle "failure".

Quote: "The client *should* do whatever is necessary to ensure it will meet the pre-conditions. It may do runtime tests or it may
assume some condition is satisfied based on its own specification"

The problem with this is that the method may have to first check internal state before adjusting the "condition", in which case the
caller will not be able to do "whatever is necessary". Furthermore, methods and "encaspulation" teach us that reusability produces
less clutter and code-bloat. If the call-stack is bloated due to runtime-checking of "conditions", well that's just business logic
coded incorrectly. Maybe the implemenation should be thought out more effeciently.

Anyway, in .NET I've never heard of the performance of an application hinging on the size of the call stack.

It seems the author is not using Exceptions as they are intended in the .NET framework. Exceptions are meant for cases where an
application (or method) cannot gracefully handle invalid conditions. Documentation provides a means for coding against methods to
insure these conditions are met prior to calling a method. If an exception is thrown, the code should be rewritten to do
runtime-checks before calling the exception-throwing method.

This is called a bug. An overlooked exception that could be handled gracefully.

If CustomType is your object, and Parse is your method (meaning that you have the ability to change the implementation), then I
would use a Try...Catch block and throw an ArgumentException when an invalid input parameter has been passed to the method.
Implement a method like "IsValid" to do a runtime check first if your concerned about the ArgumentException being thrown. After
all, it's an "exception" to your code, something that has not been accounted for.

No user wants to see a Debug.Asser popup while running there application. This is for debug use only on a development and testing
platform.

I hope I've cleared it up (and didn't offend anyone)

GL

--
Dave Sexton
dave@www..jwaonline..com
-----------------------------------------------------------------------
<ar****@yahoo.com> wrote in message news:11**********************@o13g2000cwo.googlegr oups.com...

I already have that, but I still need to use it in try-catch, don't I?

This is what I wanted to acheive:

http://c2.com/cgi/wiki?DesignByContract

But I can't explain it because I think I haven't grasp it properly as
well. I know that much that it tries to separate the implementation
from what we are expectnig to see on the output, the main reason for
doing that is to catch the errors before hand. As it is suggested in
the above URL I believe XP Unit-Testing can replace it.