Catch in procedure with out return

  • Thread starter Thread starter Jeff User
  • Start date Start date
J

Jeff User

Hi
I wanted to write a general procedure to handle all my errors.
My idea was to place various stuff in the error handler then call it,
from all my "Catch" blicks, ending it the Exception.

public whatever Procedure_1()
.....
catch(Exception er)
{
CallErrHandler(er);
}

.....

The error handler routine would actually re-throw the exception after
doing its other tasks (logging, re-wording, etc)
So, If an error occurs, there will never be a "return" from the
Procedure_1.
The compiler though, requires a return clause.

Is there any way around this?
Thanks
Jeff
 
Jeff said:
I wanted to write a general procedure to handle all my errors.
My idea was to place various stuff in the error handler then call it,
from all my "Catch" blicks, ending it the Exception.
Click to expand...

The error handler routine would actually re-throw the exception after
doing its other tasks (logging, re-wording, etc)
So, If an error occurs, there will never be a "return" from the
Procedure_1.
The compiler though, requires a return clause.

Is there any way around this?
Click to expand...

Yes, although it's not nice:

CallErrHandler(...);
// Compiler doesn't know we never get this far
return null;

It's nasty, but it works. It doesn't help your coverage data though :(

If you're using C# 2.0, you could make CallErrHandler a generic method,
something like:

public T CallErrHandler<T> (parameters as before)
{
// Code as before
return default(T);
}

And then make your code "return" the value returned from
CallErrHandler<T>, using an appropriate version for your call. You may
have to work to persuade the compiler that it'll get as far as the
return value in CallErrHandler though!

Jon
 
If you're using C# 2.0, you could make CallErrHandler a generic method,
something like:

public T CallErrHandler<T> (parameters as before)
{
// Code as before
return default(T);
}

And then make your code "return" the value returned from
CallErrHandler<T>, using an appropriate version for your call.
Click to expand...

I ask this out of sheer ignorance: can T be "void" here? It could in C++,
where:

void B();
void A()
{
return B();
}

was made legal to help templates do things like your suggestion.
(Parenthetically, I think the above code is perfectly sensible even in the
absence of generics/templates.)
 
Mike said:
I ask this out of sheer ignorance: can T be "void" here? It could in C++,
where:

void B();
void A()
{
return B();
}

was made legal to help templates do things like your suggestion.
(Parenthetically, I think the above code is perfectly sensible even in the
absence of generics/templates.)
Click to expand...

I don't *think* so, but I'd have to check. I don't know what the value
of default(void) would be...

Of course, it wouldn't actually matter if the method you're in the
middle of returned void - you could just call CallErrHandler and ignore
the return value.

Jon
 
The error handler routine would actually re-throw the exception after
doing its other tasks (logging, re-wording, etc)
So, If an error occurs, there will never be a "return" from the
Procedure_1.
The compiler though, requires a return clause.

Is there any way around this?
Click to expand...

Hi,

hope you understand the problem so I will not explain it.

solution: IF the error handler will throw an exception what if you recode it
to looks like:

public Exception CallErrHandler( Exception e) { ... }

then you can code it like

catch(Exception er)
{
throw CallErrHandler(er);
}



The compiler will not complain and the semantics is clear enough.
 
Jeff said:
Hi
I wanted to write a general procedure to handle all my errors.
My idea was to place various stuff in the error handler then call it,
from all my "Catch" blicks, ending it the Exception.

public whatever Procedure_1()
....
catch(Exception er)
{
CallErrHandler(er);
}

....

The error handler routine would actually re-throw the exception after
doing its other tasks (logging, re-wording, etc)
So, If an error occurs, there will never be a "return" from the
Procedure_1.
The compiler though, requires a return clause.

Is there any way around this?
Click to expand...

I have one more work around suggestion.

catch(Exception er)
{
CallErrHandler(er);
throw; // this statement will never be reached. CallErrHandler throws
exception for us.
}

by the way, when you rethrow the exception in CallErrHandler, it messes up
the stack trace.

--
Reginald Blue
"I have always wished that my computer would be as easy to use as my
telephone. My wish has come true. I no longer know how to use my
telephone."
- Bjarne Stroustrup (originator of C++) [quoted at the 2003
International Conference on Intelligent User Interfaces]
 
Back
Top