I'm going to develop java SIM toolkit applets.
One of my difficulties is when I have an exception in my code I don't know how to understand what is the exception?
try {
reg.initMenuEntry(MenuItem1, (short) 0, (short) MenuItem1.length, PRO_CMD_DISPLAY_TEXT, false, (byte) 0, (short) 0);
} catch (Throwable t) {
}
E.g. in above statement if an exception happens, I don't know how to handle the exception and understand what is the cause of exception?
P.s. Is catching Throwable a good idea (instead of exception)? I tried to catch Throwable since it is parent of Exception itself.
Some JavaCard platforms come along with a debugger, but this is mostly depending on the vendor, so you have to contact your supplier/vendor.
For some easy lightweight debugging, you can catch Exception and compare this with the different specific Exceptions provided by the documentation and throw specific ISOException errors, in that way if it crashes you don't always get 0x6f00, but you could throw 0x6f01 for OutofBoundsException, 0x6f02 for NullPointerException and so on...
Related
Is it possible in Drools to throw an exception or should I return a String and when I get the response should I verify the String I received?
Example:
package droolsvalidation.droolsvalidation;
import drools.validation.Code;
rule "MyRule"
when
c: Code(code==null)
then
throw Exception
end
How can I do that if it's possible or how can I handle it?
And it would be great if you can show an example of how can I catch that Exception.
It is possible, yes, but I don't know if it is recommended. In any case, you can handle exceptions thrown during the execution of a KieBase by registering a ConsequenceExceptionHandler to it.
This answer explains the mentioned approach.
Hope it helps,
Version 1.0
Let's say in the punctuate method of lowlevel processor, creation of a dummy file fails with an exception. How to stop the stream application when an exception is encountered?
I was wondering if there is a way to throw an exception, but could not add throw clause on the init method. The following requires to be surrounded by a try-catch OR an exception to be thrown and can't use either one. Please suggest.
Files.createFile(Paths.get(dummyFile));
you could wrap IOException into any unchecked exception like RuntimeException, or would be better to create your own that will extend from RuntimeException, and throw it. if your method throw exception for any incoming message, stream will be in a dead state, so stop consuming messages until you restart application
My Entity Framework will always targeting SQL Server.
So, in my program. What type of exception shall I catch?
DataException or SqlException ?
and in DAL, is it good to throw the exception again after logging?
I would suggest multiple catch and log both.
In live environment its not recommended to throw error to client system, however you always need to throw the error.
So its your call how to do it.
If its live show a beautiful error to client that something went wrong and we are looking.
I have a few doubts regarding exception handling in iPhone. Here are they:
Suppose I have a chain of methods which are being called one after the other, that is, method A calls method B, which in turn calls method C, which calls method D. Which is the best place to put my try-catch block (is it method A or B or C or D or all of them). Also, I need to display an alert to user that an exception has occured and then, I want to log this exception to my server. So, if I am writing my try - catch block in all of this methods and if an exception occurs in method D; then I think the alert will be displayed 4 times and the web service for logging will also be called 4 times (till control reaches to catch block of method A). So, should I just use #throw; in catch block of method B, C and D and write my logic in catch block of method A (top level method) or should I avoid writing try - catch at all in methods B,C and D.
I need some sort of error code from the exception (because my web service needs parameters error-code and description). Is it possible to convert an exception to error or will I need to hard-code this code?
I had read somewhere about NSSetUncaughtExceptionHandler. And I think, if I can set this handler (in appDidFinishLaunching method of app delegate) and in the handler method, if I show to user some alert and call the web service; then I need not write try - catch block in each of my methods, in each of my classes. Am I right??
If an exception has occured and I have written either a try - catch block or NSSetUncaughtExceptionHandler, then will my app continue running or it will not respond to any of the user events. (I am sure it will handle the crash. What I want to know is whether it will hang)
Someone please enlighten me on this EXCEPTION TOPIC.
0) Avoid exceptions in Cocoa. They are generally non-recoverable. You might catch them for your own error reporting, but it's generally unsafe to assume you can recover from them.
1) If you need to catch, catch it immediately. Don't write your own throws -- instead, convert it to something like an NSError and pass that around. NSError can contain all the information you need to display or send an error code as well as a localized message.
2) You cannot convert an NSException into an NSError (directly) because an NSException does not have all the properties an NSError has - it is a different data representation. For one, an error code is not available. Two, the description is not localized. The best you can do is to create an error code and domain, then use the properties you need from the NSException and store that in an NSError. This could look something like the following:
// error checking omitted
extern NSString* const MONExceptionHandlerDomain;
extern const int MONNSExceptionEncounteredErrorCode;
NSError * NewNSErrorFromException(NSException * exc) {
NSMutableDictionary * info = [NSMutableDictionary dictionary];
[info setValue:exc.name forKey:#"MONExceptionName"];
[info setValue:exc.reason forKey:#"MONExceptionReason"];
[info setValue:exc.callStackReturnAddresses forKey:#"MONExceptionCallStackReturnAddresses"];
[info setValue:exc.callStackSymbols forKey:#"MONExceptionCallStackSymbols"];
[info setValue:exc.userInfo forKey:#"MONExceptionUserInfo"];
return [[NSError alloc] initWithDomain:MONExceptionHandlerDomain code:MONNSExceptionEncounteredErrorCode userInfo:info];
}
#catch (NSException * exc) {
NSError * err = NewNSErrorFromException(exc);
...
}
If the APIs you use throw exceptions you are expected to catch and recover from (e.g. not truly exceptional cases), then yes, you could catch and attempt to continue. Unfortunately, anybody that writes exceptions in Cocoa with the intent that you will catch them probably does not understand the issues well enough to implement a solid unwind implementation (e.g. even if it produces leaks, it's not solid).
3) That's really not the time or place to display an alert. If you install a top level exception handler (via NSSetUncaughtExceptionHandler) - You should simply log a message -- then the exception handler will abort. Your app is in an unstable state -- continuing is worse than aborting. You may want to send these custom messages home, it's best to do so at the next launch of your app.
4) In the majority of cases, your app is in an unstable state and you should not continue. But, to actually answer it for those corner cases: "Yes, you can recover and continue when you catch, but you should only attempt to recover and continue when the throwing API states that recovery is supported. If the problem is beyond your control, and the problem is not exceptional (e.g. file not found), and the vendor really expects you to continue, then I would have to assume that they expect you to continue, even though it really isn't (100% safe).". Do not attempt to recover/continue from within your top level exception handler (the program will abort after it returns). If you want to be very fancy and present that immediately on OSX, another process would be best. If you are calling through a pure C++ interface, then the unwinding is well defined, and the need to catch is necessary - do continue if it is recoverable. Exceptions in C++ can be recoverable and well defined - they are also used quite extensively (including less than exceptional conditions).
(IMO...) Exceptions in ObjC should not have been introduced, and any method that throws from system or third party libraries should be deprecated. They don't unwind well, or in a well defined manner. As well, unwinding flows against normal Cocoa program flow. That means that touching any objc object's memory/relations that was in mutation at the time of the throw and which lies between the throw and the catch is as good as undefined behaviour. Problem is - you have no idea what that memory is (in most cases, and within reasonable maintenance time). C++ exceptions are well defined, and they unwind correctly (e.g. destructors are called) - but trying to continue in an ObjC context is ignoring any consequences of undefined behavior. IMO, they should only exist for ObjC++ (because C++ requires them).
In an ideal world, your ObjC programs and the libraries you use would not use exceptions (at all). Since you use libraries that do throw (including Cocoa), install a top level exception handler only if you need some special information about the error. Where the API mandates that you could expect an exception thrown due to circumstances beyond your control and you are expected to recover, then write a catch but immediately convert that logic to normal program flow (e.g. NSError) - you never need to write your own throw. -[NSArray objectAtIndex: and "object does not respond to selector" are examples of programmer errors - they should not be caught, but the program should be corrected.
I am using Restkit's object manager to handle a good chunk of my remote API calls.
It throws NSAssert for a wide range of errors. For example, if the server returns a error page as opposed to well-formed JSON, it will raise an NSAssert, even if there is nothing wrong with the code.
There are a few things I am confused about (most of which has to do with general handling of exceptions and nsasserts).
How should we handle these NSAsserts errors? For example, we would want to retry again for a few times, then show a "something went wrong" message (as opposed to crashing the application).
I tried to use a catch-try block to catch the errors (code below), but the errors are not being caught. So my app just keeps failing. Furthermore, I am not comfortable using try-catch in release mode anyway.
Just for my understanding, why do Restkit use NSAsserts, as opposed to other failure?
Code:
// code to catch NSAssert that sharedManager throws
#try{
[sharedManager loadObjectsAtResourcePath:self.resourcePath delegate:self];
}
#catch (NSException *ex) {
NSLog(#"exception caught");
}
In general, you should NOT try to catch NSAssert errors, as they mean that something went horribly wrong - e.g. an application internal state become inconsistent, your are using library incorrectly etc., - and so application needs to quit.[1]
The reason your errors are not being caught is because NSAssert raises an NSInternalInconsistencyException[2], which is a string and not an instance of NSException. You can still catch them as per[3], e.g. with
#catch (id ex)
but it's not recommended for the reasons listed above.
To answer your 3rd question, please provide more details around which NSAssert is raised etc.
[1] What's the point of NSAssert, actually?
[2] http://developer.apple.com/library/mac/#documentation/Cocoa/Reference/Foundation/Miscellaneous/Foundation_Functions/Reference/reference.html#//apple_ref/c/macro/NSAssert
[3] http://developer.apple.com/library/mac/#documentation/Cocoa/Conceptual/Exceptions/Tasks/HandlingExceptions.html