Good programming style?

  • Thread starter Thread starter codymanix
  • Start date Start date
C

codymanix

Is it bad style if I have a method that returns (not throw!) an exception?
It depends on the circumstances wheather I want to throw an exception or
just want to test the consistency of the data. since the my exception class
already holds all data about the problem i would just make a method like
this:

PositionIncompleteException TestComplete()
{
if (!Complete)
return new PositionIncompleteException (posID, errorString);
else
return null;
}
 
You don't need to return an exception, you just throw it and then you can
catch it from a layer above. Example:

public void SomeMethod()
{
try
{
TestComplete();
}
catch(PositionIncompleteException ex)
{
// do whatever you need to do with the exception object
}
}

public void TestComplete()
{
if (!Complete)
throw new PositionIncompleteException (posID, errorString);
}


hope this helps

Fitim Skenderi
 
You don't need to return an exception, you just throw it and then you can
catch it from a layer above. Example:
Click to expand...


The problem is that throwing exceptions is very very slow in .NET. I'll hope
they will fix that.
I want a quick test to run if all my positions are complete. If one of them
is not, then it is not an error.
But when I call this test in the method that serializes the data the
information _must_ be complete so i would then throw the returned exception.
 
Yeah I think I would agree throw the exception if you can, its a little more conventional and clearer to other programmers who read the code

----- Fitim Skenderi wrote: ----

You don't need to return an exception, you just throw it and then you ca
catch it from a layer above. Example

public void SomeMethod(

tr

TestComplete()

catch(PositionIncompleteException ex

// do whatever you need to do with the exception objec



public void TestComplete(

if (!Complete
throw new PositionIncompleteException (posID, errorString)



hope this help

Fitim Skender
 
codymanix said:
The problem is that throwing exceptions is very very slow in .NET. I'll hope
they will fix that.
Click to expand...

It's not *that* slow. On my box it takes about 12 seconds to
throw/catch a million exceptions. In most cases, the inefficiency of
throwing an exception isn't going to be a problem - it's just not
generally nice design.
I want a quick test to run if all my positions are complete. If one of them
is not, then it is not an error.
Click to expand...

In that case, I'd use a test method which returns a straight boolean.
 
The first time you throw an exception it may be slow to run because
certain some new parts of your program code needs to be changed into
native language, but this has nothing to do with the speed of the
exception code itself.
Click to expand...

It sometimes takes up to 4 seconds on my computer when the first exception
is thrown.
But it can be that this is only in debugging mode.
 
The first time you throw an exception it may be slow to run because
certain some new parts of your program code needs to be changed into
native language, but this has nothing to do with the speed of the
exception code itself.
 
codymanix said:
Is it bad style if I have a method that returns (not throw!) an exception?
It depends on the circumstances wheather I want to throw an exception or
just want to test the consistency of the data. since the my exception class
already holds all data about the problem i would just make a method like
this:

PositionIncompleteException TestComplete()
{
if (!Complete)
return new PositionIncompleteException (posID, errorString);
else
return null;
}
Click to expand...

You might return a bool, and use two out parameters:

if (!TestComplete(out posID, out errorString)) {
DoSomethingExotic(posID, errorString);
}

or perhaps:

string errorString = TryCompleteTest(out posID);
if (errorString != null) {
DoSomethingExotic(posID, errorString);
}

or even:

class TestError
{
int posID;
string message;

// ... properties, etc.
}

TestError e = TryCompleteTest();
if (e != null) {
DoSomethingExotic(e);
}

or perhaps:

TestError e;
if (TestComplete(out e)) {
DoSomethingExotic(e);
}
 
That's running inside of the debugger, right? There is a large and
noticeable performance hit when an exception is thrown in a debugging
session. My guess would be that has something to do with VS.Net
intercepting the exception for debugging information. If you run release
code outside of the debugger, you don't get such a terrible hit.
 
You could (I wouldnt recommend it)
but look at it this way... Consider you wish to go that route

1. Your method (TestComplete) is explicitly stating its going to have a
PositionCompleteException. So in essence it reads "The function
TestComplete is successful if it throws a PositionCompleteException".
2. You would end up checking for the exception in the calling method.
May be something like this
public void Foo() {
if(TestComplete() != null) {
//Do something
}
else {
//Do something else
}
}
Now what if you want the caller of Foo to be notified of the exception?

I'd say its not a good style at all. Hope that helps
 
It is a weird programming style. You don't want to throw an exception
but still want a type of exception. Why do you want an exception type ?
Or, is the object's identifier named "...exception"? Please clarify.

with regards,


J.V.Ravichandran
- http://www.geocities.com/
jvravichandran
- http://www.411asp.net/func/search?
qry=Ravichandran+J.V.&cob=aspnetpro
- http://www.southasianoutlook.com
- http://www.MSDNAA.Net
- http://www.csharphelp.com
- http://www.poetry.com/Publications/
display.asp?ID=P3966388&BN=999&PN=2
- Or, just search on "J.V.Ravichandran"
at http://www.Google.com
 
J.V,

Wierd is perhaps a bit strong. For example if your use p/Invoke and an
API
call failes, then you can create a Win32Exception based on the information
retunred by Marshal.GetLastWin32Error() and in many cases you would not
want to throw it. I agree that it may not be the best of designs but I am
just
saying that it does occure =)

//Andreas
 
Back
Top