Exceptions
-
I have an existing code base, which we catch exceptions etc. Does anyone know if there is a way to list all the exceptions that either the code catches or raises so that I can do a review? reason for the review is the result of a pen test, which they flagged that the responses had too much details inside the exception.
Every day, thousands of innocent plants are killed by vegetarians. Help end the violence EAT BACON
-
I have an existing code base, which we catch exceptions etc. Does anyone know if there is a way to list all the exceptions that either the code catches or raises so that I can do a review? reason for the review is the result of a pen test, which they flagged that the responses had too much details inside the exception.
Every day, thousands of innocent plants are killed by vegetarians. Help end the violence EAT BACON
-
I have an existing code base, which we catch exceptions etc. Does anyone know if there is a way to list all the exceptions that either the code catches or raises so that I can do a review? reason for the review is the result of a pen test, which they flagged that the responses had too much details inside the exception.
Every day, thousands of innocent plants are killed by vegetarians. Help end the violence EAT BACON
VS can do a "Find in files" across a whole project or solution, and that can be a regex. So "\scatch\s" and "\sthrow\s" would find and list them all in the "Find" pane (which can be copied to the clipboard) or double clicked to go to each in turn)
"I have no idea what I did, but I'm taking full credit for it." - ThisOldTony "Common sense is so rare these days, it should be classified as a super power" - Random T-shirt AntiTwitter: @DalekDave is now a follower!
-
I'd probably use Notepad++ to do a File Content search for "Catch" and "Throw" on my project folder
Thanks, was wondering there was a clever way to do this but sadly not. Thanks for you time :thumbsup:
Every day, thousands of innocent plants are killed by vegetarians. Help end the violence EAT BACON
-
VS can do a "Find in files" across a whole project or solution, and that can be a regex. So "\scatch\s" and "\sthrow\s" would find and list them all in the "Find" pane (which can be copied to the clipboard) or double clicked to go to each in turn)
"I have no idea what I did, but I'm taking full credit for it." - ThisOldTony "Common sense is so rare these days, it should be classified as a super power" - Random T-shirt AntiTwitter: @DalekDave is now a follower!
Thanks, was wondering there was a clever way to do this but sadly not. Thanks for you time :thumbsup:
Every day, thousands of innocent plants are killed by vegetarians. Help end the violence EAT BACON
-
I have an existing code base, which we catch exceptions etc. Does anyone know if there is a way to list all the exceptions that either the code catches or raises so that I can do a review? reason for the review is the result of a pen test, which they flagged that the responses had too much details inside the exception.
Every day, thousands of innocent plants are killed by vegetarians. Help end the violence EAT BACON
In my experience the most interesting exceptions are the ones we do not throw or catch ourselves, but we get for free by calling some CLR class. Example:
Image.FromFile()can throw anOutOfMemoryExceptionwhen the file's format isn't recognized! Now how do you make sure your code base handles that properly???Luc Pattyn [My Articles] The Windows 11 "taskbar" is disgusting. It should be at the left of the screen, with real icons, with text, progress, etc. They downgraded my developer PC to a bloody iPhone.
-
I have an existing code base, which we catch exceptions etc. Does anyone know if there is a way to list all the exceptions that either the code catches or raises so that I can do a review? reason for the review is the result of a pen test, which they flagged that the responses had too much details inside the exception.
Every day, thousands of innocent plants are killed by vegetarians. Help end the violence EAT BACON
Log them in FirstChanceException. Have a white / black dictionary / list as you work through them.
Quote:
This event is only a notification. Handling this event does not handle the exception or affect subsequent exception handling in any way. After the event has been raised and event handlers have been invoked, the common language runtime (CLR) begins to search for a handler for the exception. FirstChanceException provides the application domain with a first chance to examine any managed exception.
[AppDomain.FirstChanceException Event (System) | Microsoft Docs](https://docs.microsoft.com/en-us/dotnet/api/system.appdomain.firstchanceexception?view=net-6.0)
"Before entering on an understanding, I have meditated for a long time, and have foreseen what might happen. It is not genius which reveals to me suddenly, secretly, what I have to say or to do in a circumstance unexpected by other people; it is reflection, it is meditation." - Napoleon I
-
I have an existing code base, which we catch exceptions etc. Does anyone know if there is a way to list all the exceptions that either the code catches or raises so that I can do a review? reason for the review is the result of a pen test, which they flagged that the responses had too much details inside the exception.
Every day, thousands of innocent plants are killed by vegetarians. Help end the violence EAT BACON
Look at the points where you expose data from the backend (typically a REST service or similar). If an exception is raised, you generally speaking just return "500 Internal Server error" without any further details - and (very important) log those details on the server. In case you use exception to trigger responses like like "404 NOT FOUND" you need to make sure they do not show stack traces or internal details as well. This is typically done in a central place in the response handler of the API so it will automatically kick in for any exception raised - you need to write this code and test it so you trust it no matter which exception is raised from the lower levels of the code. Then you do not need to hunt your entire code base for possible exceptions - which is an impossible task anyway as some system exceptions can be raised from anywhere. Java tried to get the code to declare all exceptions so you could track it down (checked exceptions) but it was not a great success. UPDATE: And make sure you only catch exceptions in 2 cases: 1) When you can FIX the issue - i.e. no error will be returned to the client, and hence no information will be leaked. Example: You want to read some data from a disk cache. If the read throws an exception catch it and recalculate the data. 2) When you can throw an exception with more details. Example: You try to read the data but the exception just says "Access denied". You know what you where trying to read and which user you where running as, so catch it and throw a new exception adding these datails - keeping the original exception as inner exception.
-
In my experience the most interesting exceptions are the ones we do not throw or catch ourselves, but we get for free by calling some CLR class. Example:
Image.FromFile()can throw anOutOfMemoryExceptionwhen the file's format isn't recognized! Now how do you make sure your code base handles that properly???Luc Pattyn [My Articles] The Windows 11 "taskbar" is disgusting. It should be at the left of the screen, with real icons, with text, progress, etc. They downgraded my developer PC to a bloody iPhone.
Thanks Luc, the reason I was asking is that we have a task from the security team who pen tested a platform we released. to review all the messages that are returned by the platform to mobile devices. this main api in this platform is large and requires a lot of reading and was wondering if I could in a automated fashion return on the exceptions rather than used human eye.
Every day, thousands of innocent plants are killed by vegetarians. Help end the violence EAT BACON
-
Log them in FirstChanceException. Have a white / black dictionary / list as you work through them.
Quote:
This event is only a notification. Handling this event does not handle the exception or affect subsequent exception handling in any way. After the event has been raised and event handlers have been invoked, the common language runtime (CLR) begins to search for a handler for the exception. FirstChanceException provides the application domain with a first chance to examine any managed exception.
[AppDomain.FirstChanceException Event (System) | Microsoft Docs](https://docs.microsoft.com/en-us/dotnet/api/system.appdomain.firstchanceexception?view=net-6.0)
"Before entering on an understanding, I have meditated for a long time, and have foreseen what might happen. It is not genius which reveals to me suddenly, secretly, what I have to say or to do in a circumstance unexpected by other people; it is reflection, it is meditation." - Napoleon I
Thanks Gerry I'll have a look into that
Every day, thousands of innocent plants are killed by vegetarians. Help end the violence EAT BACON
-
I have an existing code base, which we catch exceptions etc. Does anyone know if there is a way to list all the exceptions that either the code catches or raises so that I can do a review? reason for the review is the result of a pen test, which they flagged that the responses had too much details inside the exception.
Every day, thousands of innocent plants are killed by vegetarians. Help end the violence EAT BACON
If you go and do a "replace all".. ..then have your exceptions inherit from a custom class inheriting from
Exception. For logging, use FirstChanceException as suggested by Gerry; it will show a lot more than the exceptions you throw yourself.Bastard Programmer from Hell :suss: "If you just follow the bacon Eddy, wherever it leads you, then you won't have to think about politics." -- Some Bell.
-
Look at the points where you expose data from the backend (typically a REST service or similar). If an exception is raised, you generally speaking just return "500 Internal Server error" without any further details - and (very important) log those details on the server. In case you use exception to trigger responses like like "404 NOT FOUND" you need to make sure they do not show stack traces or internal details as well. This is typically done in a central place in the response handler of the API so it will automatically kick in for any exception raised - you need to write this code and test it so you trust it no matter which exception is raised from the lower levels of the code. Then you do not need to hunt your entire code base for possible exceptions - which is an impossible task anyway as some system exceptions can be raised from anywhere. Java tried to get the code to declare all exceptions so you could track it down (checked exceptions) but it was not a great success. UPDATE: And make sure you only catch exceptions in 2 cases: 1) When you can FIX the issue - i.e. no error will be returned to the client, and hence no information will be leaked. Example: You want to read some data from a disk cache. If the read throws an exception catch it and recalculate the data. 2) When you can throw an exception with more details. Example: You try to read the data but the exception just says "Access denied". You know what you where trying to read and which user you where running as, so catch it and throw a new exception adding these datails - keeping the original exception as inner exception.
-
Isn't there an option to hide that?
Bastard Programmer from Hell :suss: "If you just follow the bacon Eddy, wherever it leads you, then you won't have to think about politics." -- Some Bell.
Probably, but hard to say without any details. I am surprised it is not the default behavior of whatever framework he is using, so maybe the default was just changed to make it easier to debug. In ASP.NET you do for example get the "to read the error details, change this setting" message - and someone not understanding the impact might just have followed these instructions. In that case the only thing he needs to do is revert that setting. But I am not going to google the solution to every imaginable framework out there, just because the poster forgot to mention what they are using. :)
-
Probably, but hard to say without any details. I am surprised it is not the default behavior of whatever framework he is using, so maybe the default was just changed to make it easier to debug. In ASP.NET you do for example get the "to read the error details, change this setting" message - and someone not understanding the impact might just have followed these instructions. In that case the only thing he needs to do is revert that setting. But I am not going to google the solution to every imaginable framework out there, just because the poster forgot to mention what they are using. :)
lmoelleb wrote:
I am surprised it is not the default behavior of whatever framework he is using, so maybe the default was just changed to make it easier to debug.
It is hidden by default because of hackers. Details should be hidden if it is not on localhost.
Bastard Programmer from Hell :suss: "If you just follow the bacon Eddy, wherever it leads you, then you won't have to think about politics." -- Some Bell.
-
lmoelleb wrote:
I am surprised it is not the default behavior of whatever framework he is using, so maybe the default was just changed to make it easier to debug.
It is hidden by default because of hackers. Details should be hidden if it is not on localhost.
Bastard Programmer from Hell :suss: "If you just follow the bacon Eddy, wherever it leads you, then you won't have to think about politics." -- Some Bell.
-
I have an existing code base, which we catch exceptions etc. Does anyone know if there is a way to list all the exceptions that either the code catches or raises so that I can do a review? reason for the review is the result of a pen test, which they flagged that the responses had too much details inside the exception.
Every day, thousands of innocent plants are killed by vegetarians. Help end the violence EAT BACON
Simon_Whale wrote:
list all the exceptions that either the code catches or raises so that I can do a review
That process would need to find that those in all of the libraries that you use also.
Simon_Whale wrote:
reason for the review is the result of a pen test,
Probably because you have an API and you are returning the exception stack trace as part of the API error handling. The solution to that is the following 1. Catch all exceptions so "catch(Exception e)" in your API layer. 2. Log the exception. You should of course already be doing this. 3. Return an error result from the API. Do not return the exception. Probably 500. But over time you can differentiate this in the error handling code. I would suggest that you also create an id and log that as well and return that as part of the error message. That way you can track an error reported from a caller back to the specific log entry. You can use a GUID but it is going to be more user friendly, especially if a UI is involved, if you create a simple id. It can rotate over time because the context of the error (when reported) is enough to localize in the logs.
