I have just asked one question here.
It is about handling exception in a dummy Library management condition. The answers on the post are convincing that I should not go for Exceptions.
But then I just read article here which very well states that and which adheres to answers given on my earlier question
You should only create a new exception if you expect developers to
take corrective action for the problem or to log for post mortem
debugging.
As we should write them to assist developers not users, does this means that Exception have their place only in libraries that will be used by developers? , and if the code is not used by other developer then we should not use any exception in it?
If this is not the case, then can anyone tell me any instance that I may need to/should use Exception in Library management project, so that I can get an idea about when I should write Exception in code which are not meant to be called by another code.
I want to focus on when and where should I write Exceptions and especially if only in Libraries.
That is perfectly fine.
Any library should not throw exception (checked exception), for the calling code. It should be handled properly by library itself.
Regarding RunTimeExceptions, it depends on design of application/library. If user can/should take any corrective measures then we should throw RuntimeExceptions else not, just log them for developer.
Related
Hi there something weird has happended to intellisense in my VS2022 development environment. For example, if I refer to an object or enumerator, intellisense offers me a list of properties/methods completely unrelated to the object I am working with, the required properties are listed, its just that they are buried amongst completely unrelated stuff.
In addition, and probably related, when I put in exception handling as in for example:
Try
Catch ex as exception
End Try
When I type 'as' a whole raft of what appears to be boilerplate code gets dumped in place of the code that I am writing, I then have to execute an undo to get back to the original code.
Can someone clarify what is happening here and perhaps suggest a solution.
Kind Regards
Paul J.
My program runs for about 10 hours during the night, sometimes I wake up to see that it has crashed (for whatever reason). It is usually a "Program Name" has stopped working, and the only button there is to close the program. I have tried watching and waiting for it to crash but the problem seems very hard to reproduce (and I can't watch it 24/7). I have used try and catch statements in my program in potentially problematic areas and told the program to dump to a text file if it catches an exception. But this isn't good enough it seems.
TLDR: Is it possible to tell my program to run a particular function when an exception has been detected in the program in general (without specifics) so that I can dump the stacktrace to a text file and investigate later?
Is it possible to tell my program to run a particular function when an exception has been detected...
Yes, but the specifics depend on the platform that you are using:
If you have a Console application, put a big Try ... Catch around Sub Main.
If you use WPF, add an event handler to AppDomain's or Dispatcher's UnhandledException event. Specifics can be found in the following question:
WPF global exception handler
In you use WinForms, you can also wrap Sub Main (which might be auto-generated) or attach to AppDomain.UnhandledException, see here for details:
WinForms Global Exception Handling?
For completeness, global exception handling in web applications is done in global.asax's Application_Error method:
How to catch unhandled exceptions in an asp.net application?
It's generally not a good idea to do this. You could, however, look at AppDomain.UnhandledException. This is pretty much restricted to one domain, and you'll also receive (potentially) notifications for all unhandled exceptions unrelated to your program.
This is usually used for class libraries, but I think with a bit of fiddle, you might get it to work.
Options:
1) When there is bad input, the app crashes and prints a message to the console saying what happened
2) When there is bad input, the app throws away the input and continues on as if nothing happened (though nothing the problem in a separate log file).
While 2 may seem like the obvious solution, the app is an engine and framework for game development, so if a user is writing something and does something wrong, it may be beneficial for that problem to be immediately obvious (app crashing) rather than it being ignored and the user potentially forgetting to check the log to see if there were any problems (may forget if the programmed behavior isn't very noticeable on screen, so he doesn't catch that it is missing).
There is no one-size-fits-all solution. It really depends on the situation and how bad the input is.
However, since you specifically mentioned this is for an engine or framework, then I would say it should never crash. It should raise exceptions or provide notable return codes or whatever is relevant for your environment, and then the application developer using your framework can decide how to handle. The framework itself should not make this decision for all apps that utilize the framework.
I would use exceptions if the language you are using allows them..
Since your framework will be used by other developers you shouldn't really constraint any approach, you should let the developers catch your exception (or errors) and manage what to do..
Generally speaking nothing should crash on user input. Whether the app can continue with the error logged or stop right there is something that is useful to be able to configure.
If it's too easy to ignore errors, people will just do so, instead of fixing them. On the other hand, sometimes an error is not something you can fix, or it's totally unrelated to what you're working on, and it's holding up your current task. So it depends a bit on who the user is.
Logging libraries often let you switch logs on and off by module and severity. It might be that you want something similar, to let users configure the "stop on error" behaviour for certain modules or only when above a certain level of severity.
Personally I would avoid the crash approach and opt for (2) that said make sure that the error is detected and logged and above all avoid any swallowing of errors (e.g. empty catch).
It is always helpful to have some kind of tracing/logging module, for instance later when you are doing performance tuning or general troubleshooting.
It depends on what the problem is. When I'm programming and writing error handling I use this as my mantra:
Is this exception really exceptional?
Meaning, is the error in input or whatever condition is "not normal" recoverable? In the case of a game, a File not Found exception on a texture could be recoverable and you could show a default texture so you know something broke.
However, if you have textures in a compressed file and you keep getting checksum errors, that would be an exceptional exception and I would crash the game with the details.
It really boils down to: can the application keep running without issue?
The one exception to this rule though (ha ha) is, if something is corrupted you can no longer trust your validation methods and you should crash as quickly as you can to prevent the corruption from spreading.
This question already has answers here:
Crash Reporter for Cocoa app [closed]
(7 answers)
Closed 3 years ago.
Are there any frameworks that capture and report exceptions? I need something that catches any exceptions or errors caused by my program while its being used by a non-technical user and then to email it to me. Do you handle this on your own projects? Did you roll your own solution or is there an off the shelf solution?
Any help would be greatly appreciated.
Exceptions are typically used in Cocoa for denoting programmer error as opposed to something going "oops" at runtime.
The classic example of the former: An Array out of bounds exception occurs if you tried accessing the 50th element of a 10 element NSArray. This is programmer error as you should not let this happen.
The classic example of the latter: You try to read in a file from disk but the file is missing. This is not an exceptional case, it's somewhat common for file read operations to fail, and thus an exception should not be thrown (it's your job as a Cocoa developer to recover from this gracefully, and it's not too difficult to do so).
Keep this in mind when using Exceptions in Cocoa, especially if they are going to be user-facing.
This may not be exactly what you are looking for, but if you use Fogbugz, there is a tool called Bugzscout that will create a ticket from the application. You could tie it into to your exception and give the user an opportunity to create a ticket on the exception:
http://www.fogcreek.com/FogBugz/docs/70/topics/customers/BugzScout.html
Theoretically, the end user should never see internal errors. But in practice, theory and practice differ. So the question is what to show the end user. Now, for the totally non-technical user, you want to show as little as possible ("click here to submit a bug report" kind of things), but for more advanced users, they will want to know if there is a work around, if it's been known for a while, etc. So you want to include some sort of info about what's wrong as well.
The classic way to do this is either an assert with a filename:line-number or a stack trace with the same. Now this is good for the developer because it points him right at the problem; however it has some significant downsides for the user, particularly that it's very cryptic (e.g. unfriendly) and code changes change the error message (Googling for the error only works for this version).
I have a program that I'm planning on writing where I want to address these issues. What I want is a way to attach a unique identity to every assert in such a way that editing the code around the assert won't alter it. (For example, if I cut/paste it to another file, I want the same information to be displayed) Any ideas?
One tack I'm thinking of is to have an enumeration for the errors, but how to make sure that they are never used in more than one place?
(Note: For this question, I'm only looking at errors that are caused by coding errors. Not things that could legitimately happen like bad input. OTOH those errors may be of some interest to the community at large.)
(Note 2: The program in question would be a command line app running on the user's system. But again, that's just my situation.)
(Note 3: the target language is D and I'm very willing to dive into meta-programming. Answers for other languages more than welcome!)
(note 4: I explicitly want to NOT use actual code locations but rather some kind of symbolic names for the errors. This is because if code is altered in practically any way, code locations change.)
Interesting question. A solution I have used several times is this: If it's a fatal error (non-fatal errors should give the user a chance to correct the input, for example), we generate a file with a lot of relevant information: The request variables, headers, internal configuration information and a full backtrace for later debugging. We store this in a file with a generated unique filename (and with the time as a prefix).
For the user, we present a page which explains that an unrecoverable error has occurred, and ask that they include the filename as a reference if they would like to report the bug. A lot easier to debug with all this information from the context of the offending request.
In PHP the debug_backtrace() function is very useful for this. I'm sure there's an equivalent for your platform.
Also remember to send relevant http headers: Probably: HTTP/1.1 500 Internal Server Error
Given a sensible format of the error report file, it's also possible to analyze the errors that users have not reported.
Write a script to grep your entire source tree for uses of these error codes, and then complain if there are duplicates. Run that script as part of your unit tests.
I know nothing about your target language, but this is an interesting question that I have given some thought to and I wanted to add my two cents.
My feeling has always been that messages for hard errors and internal errors should be as useful as possible for the developer to identify the problem & fix it quickly. Most users won't even look at this error message, but the highly sophisticated end users (tech support people perhaps) will often get a pretty good idea what the problem is and even come up with novel workarounds by looking at highly detailed error messages. The key is to make those error messages detailed without being cryptic, and this is more an art than a science.
An example from a Windows program that uses an out-of-proc COM server. If the main program tries to instantiate an object from the COM server and fails with the error message:
"WARNING: Unable to Instantiate
UtilityObject: Error 'Class Not
Registered' in 'CoCreateInstance'"
99% of users will see this and think it is written in Greek. A tech support person may quickly realize that they need ro re-register the COM server. And the developer will know exactly what went wrong.
In order to associate some contextual information with the assertion, in my C++ code I will often use a simple string with the name of the method, or something else that makes it clear where the error occured (I apologize for answering in a language you didn't ask about):
int someFunction()
{
static const std::string loc = "someFunction";
: :
if( somethingWentWrong )
{
WarningMessage(loc.c_str(), "Unable to Instantiate UtilityObject: Error 'Class Not
Registered' in 'CoCreateInstance);
}
}
...which generates:
WARNING [someFunction] : Unable to
Instantiate UtilityObject: Error
'Class Not Registered' in
'CoCreateInstance