I'm learning Objective-C from the book "Programming in Objective-C" and find myself comparing it to Java. They are obviously very different languages, but the similarities are striking. Near the end of chapter 9 the author issues the following statement;
It is strongly recommended that if you catch an exception you only do
so with the intention of cleaning up and terminating your application.
Why? Because Apple does not guarantee that your application will be in
a well-defined state for continuing program execution once an
exception is thrown.
This is very different from Java, where depending on the exception itself, you can continue program execution (eg: if you try opening a configuration file, but get an exception of "File not found", you can select some default values and continue without issues). I believe the same is true for C#/.NET. Probably for python too, but I'm no authority.
I'm guessing that since Objective-C isn't running on some framework/runtime-environment, Apple can't make any guarantees about program state after an exception is thrown. But that still feels weird since, it defeats one of the biggest selling points of OOP (to isolating issues from propagating unchecked) i.e. if your code catches an exception (barring the object that threw the exception), the rest of your program should be fine.
Without knowing how Apple's Objective-C works underneath, I don't think it will be easy to puzzle out. This got me wondering;
From an academic perspective (and simple curiosity) - In what modern OOP languages+environments will an application be in a potentially unstable state after an exception is thrown?
Related
I am new to Rust and have come to understand Rust defaults to panics and not exceptions.
I have a rust project that depends on external libraries.
I have handled all unwraps and ?'s in my code using match statements, but I am not sure how to handle a panic by external libraries.
In other languages I would just catch an exception thrown by the library.
As Rust defaults to panics, the libraries don't return an exception but panic and thus abort execution of the thread.
I would ideally want to log and continue execution, not panic and abort.
I have tried the following:
catch_unwind, but this looks like something I can't use on an external library.
log-panics crate, which logs the panic using a panic hook. I am able to log the panic, but not prevent aborts.
DON'T PANIC
I mean, that's the real solution: you must avoid panics, not try to recover from them when they happen.
Some languages casually use exceptions to deal with conditions preventing some operations, and manage them without crashing.
In Rust, those unsupported conditions are managed with errors, not panics.
A panic in Rust is
most often a bug, usually temporary because you've put an unwrap in your first prototyping
or a very extraordinary condition
As the Book says:
When code panics, there’s no way to recover
The various utilities like catch_unwind are, at best, aiming at more gracefully quitting, they don't let your program run as if nobody happened.
When a crate you use panics, first check you're using the function as expected (and if you can't check that without panicking that's a bug in that lib), then either have it fixed or fix it yourself if you can.
There's no reasonable way to deal with a casual panic, apart from crashing as fast as possible. A panic isn't casual in the life of your program.
I'm working on a VB.Net program in debug in Visual Studio 2010 (10.0.40219.1) (Windows XP 5.1 2600.xpsp-sp3-gdr.120821-1629), and have noticed that while debugging it runs very slowly. When run as an executable (even the debug executable) it bowls along at a splendid speed.
The cause appears to be that the development environment is generating large numbers of exceptions (appearing in the immediate window).
A first chance exception of type 'System.ArgumentNullException
occurred in Microsoft.VisualBasic.dll
Does anyone know what the cause of this might be? It doesn't appear to have any adverse effect on the running of the program, other than to take a long time to get to the bit I'm trying to find the bug in. The exception doesn't appear to be related to any particular patch of code, and indeed it doesn't happen for most other projects.
I found an answer to a similar question for you:
A first chance exception
I would pay specific attention to the suggestion by Marcus Andren:
If you want to pinpoint where the exceptions are occurring, you can
select the Debug->Exceptions menu item, and in the dialog that
appears, check the first checkbox for "Common Language Runtime
Exceptions". This will make the debugger break as soon as an exception
occurs instead of only breaking on unhandled exceptions.
This is also one reason why it is generally a bad idea to catch
generic exceptions unless you are clearly logging the information
caught.
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.
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