Error Code Reference for OSX/Cocoa - cocoa

If I get an error code result from a Cocoa function, is there any easy way to figure out what it means (other than by grepping through all the .h files in the framework bundles)?

You should look at the <Framework/FrameworkErrors.h> header for whatever framework the method you're using that's returning an error comes from.
For example, an NSError in the Cocoa domain that you get from a method in the Foundation framework will have its code property described in the <Foundation/FoundationErrors.h> header. Similarly with AppKit and <AppKit/AppKitErrors.h> and Core Data and <CoreData/CoreDataErrors.h>.
Also, if you print the description of the NSError in the debugger, it should include not only the error domain and code, but also the name of the actual error code constant so you can look it up in the API reference.

The sections on 'Error Domains' and 'Error Codes' in Apple's Error Handling Programming Guide address this reasonably well. You need to do the following:
Log the error, taking note of both the error domain (a human-readable / Googleable string that tells you where to look for the error code definitions) and the error code itself (an integer)
Sniff around on Google (or read from the list below) and figure out the name of the header file(s) where the error codes for that error domain are defined
Search those header file(s) for the error code you got. You should find both a constant name for the error code (like ENOMEM), and hopefully also an explanatory comment (like /* Cannot allocate memory */) explaining what the error means. If there's no comment, and the constant name isn't self-explanatory, just Google the constant name and you'll probably find a proper description.
Some header files of major error domains:
NSCocoaErrorDomain
Error code declarations are spread across three header files:
<Foundation/FoundationErrors.h> (Generic Foundation error codes)
<AppKit/AppKitErrors.h> (Generic AppKit error codes)
<CoreData/CoreDataErrors.h> (Core Data error codes)
NSURLErrorDomain
Check NSURLError.h
NSXMLParserErrorDomain
CheckNSXMLParser.h
NSMachErrorDomain
Check /usr/include/mach/kern_return.h
NSPOSIXErrorDomain
Check /usr/include/sys/errno.h
NSOSStatusErrorDomain
Check
/System/Library/Frameworks/CoreServices.framework/Frameworks/CarbonCore.framework/Headers/MacErrors.h

Also, Cocoa's NSError is meant to be displayable to the end user. If you just log it, it should be readable.
If you're talking about Carbon's OSStatus and such, MacErrors.h.

For NSError errors add a line of code:
NSError *error;
// ... Some code that returns an error
// Get the error as a string
NSString *s = [error localizedDescription];
// Observe the code for yourself or display to the user.

Related

How to have usefull debugging or error messages from laravel

I'm a bit new to laravel, but I'm experienced in Php.
In previous works, I set a mecanism that allowed me to be informed when nearly any problem occurred on the server:
I got full stack
precise PHP error messages
for nearly all king of errors
a mail sent to me
So when I began to work with laravel, I tried to do the same things, and achieved:
full stack
a mail sent to me
But I can't have meaningful error in all case. One example:
$store = Store::create(...)
In this line I forget to specify the namespace (\App\Store::create), and I get those error messages:
first:
FatalThrowableError ; Type error: Argument 1 passed to App\Http\Controllers\User::create() must be an instance of Illuminate\Http\Request, array given, called in /var/www/html/laravel/blog/app/Http/Controllers/User.php on line 94
second:
ErrorException ; Trying to get property of non-object in VerifyCsrfToken.php (line 156)
third:
FatalThrowableError ; Type error: Argument 1 passed to Illuminate\Session\Middleware\StartSession::addCookieToResponse() must be an instance of Symfony\Component\HttpFoundation\Response, array given, called in /var/www/html/laravel/blog/vendor/laravel/framework/src/Illuminate/Session/Middleware/StartSession.php on line 72
I understand that laravel is a complex framework but I can't figure why it produces this errors, and how I can have more useful errors (as as it is I can only know that "something is bad").
Has someone an idea ?
ยน There is some errors that Php prefers to keep to himself (in its logs) :-)
When you start a new Laravel project, error and exception handling is
already configured for you. The App\Exceptions\Handler class is where
all exceptions triggered by your application are logged and then
rendered back to the user.
https://laravel.com/docs/5.4/errors
I recommend you to dive into the official docs and into your App\Exceptions\Handler.
Maybe you are looking for report and render methods in that class.
I finally cornered the problem and I learned a lot.
I thank for their benevolence #Don't Panic and #Vitalmax !
The error was that I forgot that PHP namespaces are case insensitive: in my post I cleaned a bit the code as I knew that it didn't stick to the code's conventions (a controller's name must begin with a capital letter). Originally my controller name was user and the faulty code was:
$user = User::create(...)
As you can guess PHP believed that I wanted to call user::create (as I have such a method in my controller) and not User::create (as I wanted).
What I learned:
don't alter the code when asking for help
Laravel use a cache system that can get in the way of the debugging (see a question that I asked on laracast's forum )
take more time to read the error message; I know this rule but I keep doing otherwise

Drupal, entity_metadata_wrappers and debugging

For handling entities in Drupal I'm using Entity Metadata Wrappers (the "Drupal way").
It's really easy to start coding and see all the advantages it has... except when you get a fatal error and you are not clear where it comes from.
This is what the database log shows:
EntityMetadataWrapperException: Unknown data property
field_whatever. at EntityStructureWrapper->getPropertyInfo()
(line 335 of
/var/www/html/sites/all/modules/entity/includes/entity.wrapper.inc).
Sadly, many times that "field_whatever" is "nid", "uid" or some very common property, so it's name is spread all over my code, which makes me difficult to get to the origin of the error.
I'm currently doing this:
Write a tiny piece of code and then run to see if something fails.
Using getPropertyInfo when handling entities with "not so common" fields.
Loosing hair.
What is worst is that sometimes the error does not appear when you are coding, but a week later. So it could be anywhere...
Is there any way of handling entity metadata wrapper errors better? Can I get better information in the database log and not just a line? A backtrace maybe?
Thanks.
Well, having the devel module active (just to see the nice krumo message) we can do something like this inside our module:
<?php
set_exception_handler('exception_with_trace');
function exception_with_trace($e)
{
dpm($e->getTrace());
}
That will return the backtrace error of the exception thrown by the entity metadata handler on the next page load (some page in your site where everything is running fine).
Also you can set the exception handler exclusively and more elegant just for some pages or some users with some role... or when some parameter in the url is met, or when in some state of your Drupal site is met (ex. when a bool persistent variable 'exception_with_trace' is true). Even, under certain conditions and control, you can use it in production too.
If the site does not work "at all" you can include it in your settings.php file, but instead of printing the trace, you must write the trace to a file and watch the trace in a different context (not Drupal but some php file).
If exceptions are too long and are causing memory problems then getting the trace as string is also possible. See http://php.net/manual/es/exception.gettraceasstring.php
Hope that helps.

Error type go lang

Is error type in Go "Error" or "error"? It bugged me that in the Tour it is with small first letter so I looked around and found here with small e yet here in source code it is with big capital letter.
Also how can it be without big capital letter yet still visible outside of package?
Just started learning Go so I might have missed something basic, thanks.
error is the type, lowercase. Just like with int and string it doesn't need to be visible as it is built-in to Go:
A good blog post on error handling
The runtime package you're referring to has an Error interface. The type there is an interface not error:
Package runtime
type Error interface {
error
// RuntimeError is a no-op function but
// serves to distinguish types that are run time
// errors from ordinary errors: a type is a
// run time error if it has a RuntimeError method.
RuntimeError()
}
The Error interface identifies a run time error.

Application.Current.Properties - System.AggregateException

I'm trying to get some data from Application.Current.Properties storage. Unfortunately, any time I want to use this Dictionary, I see this error:
An exception of type 'System.AggregateException' occurred in mscorlib.ni.dll but was not handled in user code
Additional information: One or more errors occurred.
And in details I found this:
{"Error in line 1 position 206. Element 'http://schemas.microsoft.com/2003/10/Serialization/Arrays:Value' contains data of the 'http://schemas.microsoft.com/2003/10/Serialization/Arrays:ArrayOfstring' data contract. The deserializer has no knowledge of any type that maps to this contract. Add the type corresponding to 'ArrayOfstring' to the list of known types - for example, by using the KnownTypeAttribute attribute or by adding it to the list of known types passed to DataContractSerializer."}
It seems like I tried to save some non-string data to Application.Current.Properties. Unfortunately I can't run .Clear() method to erease all data, bacause I receive this error any time I'm trying to access this property.
What should I do to make it work?
Well, as its name suggests AggregateException, is just a container for one or more exceptions which may be thrown when using PLINQ or TPL.
As such exceptions may be thrown on different threads and may also occur concurrently, the system automatically catches and rethrows them within an AggregateException wrapper to ensure that they all get reported in one place. The exceptions themselves are exposed via the InnerExceptions property.
You can catch an AggregateException and check which exceptions it actually contains with code such as the following:
try
{
// perform some parallel operation
}
catch (AggregateException aex)
{
string messages = "";
foreach(Exception ex in aex.InnerExceptions)
{
messages += ex.Message + "\r\n";
}
MessageBox.Show(messages);
}
So I suggest you do this to see what is causing the problem
Please, remove your app from your device, Settings - Applications- Uninstall, this works for me. The Auth Object was crash in debug mode.Clean and Rebuild can be Helpfull to.

Uploadify v3 onUploadError howto

Been playing around with Uploadify v3 for few days now and just came to realize some of the codes have been rewritten, for example, onError is no longer existed, I am assuming it's been replaced by onUploadError.
What i am trying to achieve is to be able to return non-compliance error to users either through putting a message in the div (preferred method) or alert.
Looking at the closest solution How to trigger uploadify onError event handler, but it's outdated as it's for v2.
Using the same method as the outdated post up there, I have $("#fileInput").uploadify() with onUploadError added:
'onUploadError' : function(file,errorCode,errorMsg) {
var r = '<br />ERROR: ';
switch(errorMsg) {
case 405:
r += 'Invalid file type.';
break;
case 406:
r += 'Some other error.';
break;
}
alert(r);
setTimeout('$("#fileInput'+ ID + 'span.data").html("'+r+'");',111);
}
The problems I am having right now are:
Alert returns undefined using the codes above
setTimeout doesn't do anything
How can you solve these problems?
Maybe it's a little too late... but anyway I try to answer.
I'm also playing around with v3 of uploadify. onError() does no longer exists, it has been replaced by onUploadError(). The erroror object given by the old onError event does no longer exists. Now to check for the type of error you can switch on the errorCode argument (the second given in the callback), which is numeric. I've not found a table with all possible error codes, but doing some trials I discovered the following three error codes:
-200: HTTP errors (e.g. HTTP 500, 400, 404, etc.)
-220: IO errors (e.g. connection closed without response from the server, or errors while rading the source file from the user's PC)
-280: don't have actually fully understood what kind of errors they are, but is seems to be errors gracefully handled by uploadify. For example, if you try to add to the queue a file that is already in the queue, uploadify ask you whether you want to replace the file that's currently enqueued, or cancel the operation. If you cancel, an error is fired with code -280.
To check for the specific type of error, for example to get the specific HTTP error code (in case the error is an http error), you can check the error message, which is the third argument. This argument is a string, not a number, so you cannot use a switch .. case as in your example (or at least it's not that simple to use a switch .. case with strings). Simply use an if .. else if .. else.
Hope this can help...
I'm still looking for a complete list of the possible error codes given in the errorCode argument of the event handler. If someone knows, please tell me!

Resources