I am coding a REST API using Perl/Mojolicious
Sometimes when I want to throw an error, for example "Invalid token" I store the error on a variable called "Object->lastError" and then I render the JSON response with the error message/code.
However it gets tedious to do it that way after a while. I was wondering if there is a better way to do this I was considering just dying and catching the die error with$SIG{__DIE__}
Any suggestions?
Also, I am not using any logger yet but I would like to log those errors
On the question of logging, see: http://search.cpan.org/~garu/MojoX-Log-Log4perl-0.10/lib/MojoX/Log/Log4perl.pm Log4perl is pretty much best practice in the wider Perl world.
Without knowing a lot of deep detail about the application, I far prefer your 'tedious' method which will [hopefully] provide some information on the receiving side of the API, rather than a crash and burn with $SIG{__DIE__}.
Hope that helps, a bit, anyway!
Related
My app is calling a web service to retrieve some data, and I want to make the experience as best as possible. I figured out that using NSURLConnection it's very hard to give good timely feedback.
Sometimes my iPhone tries to load the data for a minute or two and I see no way of figuring out what is taking so long, or why the download is so troublesome. Then after a few minutes I sometimes end up with an error code.
I'd like to display exactly what is happening. Messages like:
"Establishing internet connection"
"Trying to connect to server"
"Connected..."
"Downloading data..."
"Download complete!"
And when there is trouble like server not reachable or DNS could not be resolved, it would be nice to just try again a few times and not simply quit and throw error.
Are there replacements for NSURLConnection which handle these things more gracefully and give better in-time feedback about what is happening?
I've been a big fan of the AFNetworking library. Very easy to use and wraps all your networking calls in blocks that are very easy to work with.
It is also is kept very current, so you should be safe in getting all the updates it needs as your project progresses and ages.
I think you should be misusing NSURLConnection and NSURLConnectionDelegate, since you can do most of you needs with them.
But, what about MKNetworkKit? I've been using it and it really makes those kind of issues easier to deal with.
Something that can help you achieve what you want. Since ASIHTTPRequest is no longer being supported MKNetworkKit would be your best choice. To check for connectivity, you can always use Reachability.
I want to modify the response that is sent when I am implementing a SOAP server using Zend_Soap_Server. I want to change the response that will be sent back because I am implementing the SOAP server for a client application that was written to work with another system but now I need to make it work with our system. The client application is expecting the XML response to be in a certain way. So what I want to do is that I dont want the handle method to put together its own XML response, I want to do it myself. Can this be done?
Thanks
I suspect there is some kind of output buffering trick you could use to do this, but a better solution might be to investigate the deeper cause of why the client is rejecting your XML and, in so doing, you may find a much more elegant solution.
For starters, you should probably read this very helpful article:
http://www.ibm.com/developerworks/webservices/library/ws-whichwsdl/
You should then investigate Zend_Soap_AutoDiscover->setOperationBodyStyle() and Zend_Soap_AutoDiscover->setOperationBodyStyle() to see if changing the encoding style or binding style solves the problem.
I trying to write a a crash report feature that when you launch the app after a crash, it will offer to send the crash report to the server. I can't find how to get the crash log within the app. I saw there is a framework that doing so (PLCrashReporter), however this framework is large and I don't need most of it's features.
Does anyone knows how to simply access the log?
Thanks,
Guy.
I guess I don't have the karma to add a comment to Nimrod Gat's answer, so I have to provide my follow-up here. I'll try to make it worthy of a standalone answer.
It's very, very difficult to write a safe, correct, and reliable crash reporter, especially one that runs directly in-process. The code referenced in Nimrod Gat's answer is not correct and honestly, that blog post should be retracted. Signal handlers must only run async-safe code, and that code isn't async-safe:
http://www.cocoadev.com/index.pl?SignalSafety
Crash handling is even more complicated than normal signal handling, because that you can't expect the process to continue to run successfully after your signal handler returns.
It's tempting to think you can just hack together a simpler solution, and it will work some of the time, but there's a good reason people like Google's engineers have thousands of LoC dedicated to reliable crash reporting:
http://code.google.com/p/google-breakpad/
On iOS, you should just use PLCrashReporter. On other platforms (such as Mac OS X) you should use Google Breakpad. There's no point in re-inventing this wheel unless you're going to do it not only correctly, but better than what already exists.
I had this similar issue and the PLCrashReported seemed too complicated for what I wanted to do.
Note that you can't access the crash report generated by Apple, the PLCrashReport generates it's own reports and store them in the user's cache folder.
Eventually, I used the following example:
http://cocoawithlove.com/2010/05/handling-unhandled-exceptions-and.html
it's very simple and easy to use, just register exception and signal handlers using:
NSSetUncaughtExceptionHandler(&HandleException);
signal(SIGABRT, SignalHandler);
signal(SIGILL, SignalHandler);
signal(SIGSEGV, SignalHandler);
signal(SIGFPE, SignalHandler);
signal(SIGBUS, SignalHandler);
signal(SIGPIPE, SignalHandler);
and get the stack trace using the backtrace method in UncaughtExceptionHandler class.
Maybe a better solution will be to use a fully specialized end-2-end solution/service? Such as http://apphance.com. It is currently in closed beta testing phase, but you can ask for participation and we'll get back to you pretty quickly. The only thing you need to do is to register for an API key and embed a small framework library into your app (or .jar file in android). Then you have remote access not only to crashlogs but also to a debug logs generated by the application - which makes it much more useful. It is for now targeted to be used during testing, but there will soon be a lite version that you will be able to embed into app-store-released application.
Inside the framework we are doing all the magic of plugging-into the apple's framework and getting the crashlog information, decoding stack traces, even handling out-of-memory cases. All the comments by #nupark hold very much true: We spend countless hours on making it works seamlessly - thread-safeness, making sure that we can do the job of saving everything within the time required by Apple's framework before your app get finally killed, getting stack trace from out-of-memory case (that one was really difficult). The same for android - we've done some clever tricks there to make sure it's really working fine.
Disclaimer: I am CTO of Polidea, company which is behind apphance and co-creator of the solution.
There are a bunch of (SAAS) E2E solutions that you may be very happy to know.
Very very simple to integrate into your application
Have Fun...
crashlytics (Free and my preferred)
hockeyapp
bugSense
Crittercism
In our days you may use the built-in crash reports (iOS & Android)
iOS (Itunes connect) - Viewing Crash Reports
Understanding Crash Reports
on iPhone OS
Reading Android Market Crash Reports
We are writing an API for iphone developers and we don't know what the best practice is for exception handling. We looked into NSError, standard POSIX way, NSException
What is the convention that most APIs use? Which is the most "Objective-C friendly"?
From the Introduction to Exception Programming Topics:
Important: You should reserve the use of exceptions for programming or unexpected runtime errors such as out-of-bounds collection access, attempts to mutate immutable objects, sending an invalid message, and losing the connection to the window server. You usually take care of these sorts of errors with exceptions when an application is being created rather than at runtime.
...
Instead of exceptions, error objects (NSError) and the Cocoa error-delivery mechanism are the recommended way to communicate expected errors in Cocoa applications. For further information, see Error Handling Programming Guide For Cocoa.
So as I understand it, only use exceptions when something is fatally wrong. Otherwise, use NSError objects.
+1 for NSError.
I forget where in the Apple docs I read this, but I also recall them encouraging the coding philosophy of "try first, then check for errors," as opposed to "check for validity, then do the operation." For example, instead of seeing if the network is available before using it, just try to use it and respond to an error if/when you get one back.
I agree with this philosophy for many use cases because (a) it moves validity-checking to the moment of action, so in a sense it's more accurate, and (b, subjective) it's more fun to work with code in this pattern.
To summarize, the suggestion is to use NSError, and to provide immediate feedback with NSError** parameters that accept NULL, to be very friendly to your API-users! This pattern is also established in several places in Cocoa/Touch; for example the NSString method writeToFile:atomically:encoding:error:.
I'm trying to make a general error handler for an iPhone app that brings the user to a recovery screen whenever any general error is thrown in the application without putting a try/catch block around every single method in the application.
Using NSSetUncaughtExceptionHandler doesn't work because the application terminates after the handler is run.
Is there any way to change this behavior, or use any other handler that will catch exceptions in general and not cause the application to exit afterward?
And please, no non-answers about whether it's a good or bad idea.
The original poster has probably solved his problem by now. However, for anyone who comes across this in the future...
Matt Gallagher wrote an excellent post on catching unhandled exceptions and signals a few months after this question was posted. I find it to be much more informative than the answer referenced above by Scott.
In particular, Matt's post describes how to attempt a recovery (if appropriate) that allows your app to keep running, and even displays a UIAlertView with error information if you want (hint: it involves creating a new run loop).
This was answered here. You can read more about the responder chain and catching the exceptions here. The write up from 1 is really good and explains how to deal with what you are doing.