Catch all but a specific exception
-
In a function, I want to catch all exceptions and just log them (they do not really matter), but one specific type of exception must not be handled like this - it must be dealt with in a function farther up the call stack. Currently, I do something like this:
private void SomeFunction()
{
try
{
//some code which might cause some exceptions
}
catch(UserTriedToCheatException)
{
throw;
}
catch (Exception ex)
{
Log(ex.ToString());
}
}Though that code works as expected, I am not content with it. That catch-throw looks so terrible. Do you have "nicer" suggestions?
-
In a function, I want to catch all exceptions and just log them (they do not really matter), but one specific type of exception must not be handled like this - it must be dealt with in a function farther up the call stack. Currently, I do something like this:
private void SomeFunction()
{
try
{
//some code which might cause some exceptions
}
catch(UserTriedToCheatException)
{
throw;
}
catch (Exception ex)
{
Log(ex.ToString());
}
}Though that code works as expected, I am not content with it. That catch-throw looks so terrible. Do you have "nicer" suggestions?
-
In a function, I want to catch all exceptions and just log them (they do not really matter), but one specific type of exception must not be handled like this - it must be dealt with in a function farther up the call stack. Currently, I do something like this:
private void SomeFunction()
{
try
{
//some code which might cause some exceptions
}
catch(UserTriedToCheatException)
{
throw;
}
catch (Exception ex)
{
Log(ex.ToString());
}
}Though that code works as expected, I am not content with it. That catch-throw looks so terrible. Do you have "nicer" suggestions?
If you're just logging the exception, why do you need an exception handler here at all? Just use the one 'further up the callstack'.
Regards, Rob Philpott.
-
If you're just logging the exception, why do you need an exception handler here at all? Just use the one 'further up the callstack'.
Regards, Rob Philpott.
Because of other code to be executed or not. Something like this:
public ReturnType APublicFunction(some params)
{
try
{
//some code here
SomeType someValue = aPrivateFunction(other params);
//some more code here
}
catch(Exception ex)
{
//do something useful with the exceptions which are caught here
}
}private SomeType aPrivateFunction(other params)
{
//some code here
SomeFunction();
//some more code here
}In case of the UserTriedToCheatException, it has to be handled in APublicFunction, and no more other code needs to be executed, while in other cases, the exceptions are not such important, the rest of the functions can still be executed (sufficient fallback functionality provided).
-
Exceptions don't really matter? Hm ... I don't find your construct too bad but the alternative which expresses your intent (imo) slightly better is:
try {
// ...
} catch(Exception ex) {
if(ex is UserTriedToCheatException) throw;
else Log(ex);
}Looks different, but not so much better that I will change my code. Thanks anyway.
-
In a function, I want to catch all exceptions and just log them (they do not really matter), but one specific type of exception must not be handled like this - it must be dealt with in a function farther up the call stack. Currently, I do something like this:
private void SomeFunction()
{
try
{
//some code which might cause some exceptions
}
catch(UserTriedToCheatException)
{
throw;
}
catch (Exception ex)
{
Log(ex.ToString());
}
}Though that code works as expected, I am not content with it. That catch-throw looks so terrible. Do you have "nicer" suggestions?
Bernhard Hiller wrote:
That catch-throw looks so terrible.
In my opinion, it won't look so terrible with some good comments around it!
The difficult we do right away... ...the impossible takes slightly longer.
-
Because of other code to be executed or not. Something like this:
public ReturnType APublicFunction(some params)
{
try
{
//some code here
SomeType someValue = aPrivateFunction(other params);
//some more code here
}
catch(Exception ex)
{
//do something useful with the exceptions which are caught here
}
}private SomeType aPrivateFunction(other params)
{
//some code here
SomeFunction();
//some more code here
}In case of the UserTriedToCheatException, it has to be handled in APublicFunction, and no more other code needs to be executed, while in other cases, the exceptions are not such important, the rest of the functions can still be executed (sufficient fallback functionality provided).
-
Looks different, but not so much better that I will change my code. Thanks anyway.
OK, but leave out the
else- it's extraneous. :) /raviMy new year resolution: 2048 x 1536 Home | Articles | My .NET bits | Freeware ravib(at)ravib(dot)com
-
Because of other code to be executed or not. Something like this:
public ReturnType APublicFunction(some params)
{
try
{
//some code here
SomeType someValue = aPrivateFunction(other params);
//some more code here
}
catch(Exception ex)
{
//do something useful with the exceptions which are caught here
}
}private SomeType aPrivateFunction(other params)
{
//some code here
SomeFunction();
//some more code here
}In case of the UserTriedToCheatException, it has to be handled in APublicFunction, and no more other code needs to be executed, while in other cases, the exceptions are not such important, the rest of the functions can still be executed (sufficient fallback functionality provided).
-
In a function, I want to catch all exceptions and just log them (they do not really matter), but one specific type of exception must not be handled like this - it must be dealt with in a function farther up the call stack. Currently, I do something like this:
private void SomeFunction()
{
try
{
//some code which might cause some exceptions
}
catch(UserTriedToCheatException)
{
throw;
}
catch (Exception ex)
{
Log(ex.ToString());
}
}Though that code works as expected, I am not content with it. That catch-throw looks so terrible. Do you have "nicer" suggestions?
Could you please clarify the meaning of up in the hierarchy or the use case where you need such type of exception handling? I am asking this only because I thing your approach could be wrong? well even I could be thinking wrong as well :-D Happy Coding
-
Could you please clarify the meaning of up in the hierarchy or the use case where you need such type of exception handling? I am asking this only because I thing your approach could be wrong? well even I could be thinking wrong as well :-D Happy Coding
For example: a program starts. Many configuration and option files are read, server connections established etc. Some problems might arise, but fallback mechanisms are provided for many cases. But somewhere down in a function, a manipulation of the license is detected - that must be raised to the topmost level, the user must be told "You bad user $€$€!" and the program shuts down immediately.
-
For example: a program starts. Many configuration and option files are read, server connections established etc. Some problems might arise, but fallback mechanisms are provided for many cases. But somewhere down in a function, a manipulation of the license is detected - that must be raised to the topmost level, the user must be told "You bad user $€$€!" and the program shuts down immediately.
Ok got it! Do following things 1. Build two separate hierarchies for exception 1.1 For exception that you want to catch log e.g. LoggableException 1.2 For exception that you want to you caller to handle e.g. NonLoggableExcptions 2. Only catch the LoggableException exceptions - log in your case 3. Don not catch NonLoggableExcptions - these will be automatically traverse to the caller 4. The try block code should only throw these two exceptions or the derived objects from these exceptions 5. Don not catch Exception, its a bad practice, which says anything could be happen in the code. can it be :-D . this gives bad impression. though I am not sure if any unhanded exception occurs how it is handled in the client server application as I never worked on it hope this helps to you and solve you problem... let me know if you need some further help Happy Coding :)
-
Ok got it! Do following things 1. Build two separate hierarchies for exception 1.1 For exception that you want to catch log e.g. LoggableException 1.2 For exception that you want to you caller to handle e.g. NonLoggableExcptions 2. Only catch the LoggableException exceptions - log in your case 3. Don not catch NonLoggableExcptions - these will be automatically traverse to the caller 4. The try block code should only throw these two exceptions or the derived objects from these exceptions 5. Don not catch Exception, its a bad practice, which says anything could be happen in the code. can it be :-D . this gives bad impression. though I am not sure if any unhanded exception occurs how it is handled in the client server application as I never worked on it hope this helps to you and solve you problem... let me know if you need some further help Happy Coding :)
did this solution helped you?
