How to print the line nuber that caused an exception in Java - exception

http://www.salesforce.com/us/developer/docs/apexcode/Content/apex_classes_exception_methods.htm#exception_common_methods This site shows that getLineNumber was included, but I am not able to use it. Thanks
( I am trying to locate a Null Pointer Exception )

a NullPointerException stack trace includes a line number, so the exception should print it.

It's unclear what you're asking, please show some code.
getLineNumber() and getStackTraceString() should include the line number (among others). Check https://developer.salesforce.com/forums?id=906F00000008xc4IAA for sample message.
As for "how to print" - there's a try-catch example. Either simply push it at System.debug() or (if it's visualforce context) you can add a pagemessage.
You can also go to setup -> debug log, attach the tracking to your user and retry the action? You'll see the stacktrace and other goodies, line numbers next to the names of called methods...

Related

AS3 - Catch ANY Error thrown and keep track of them?

I would like to have many devices testing a game, and I find the best way to debug a game and solve specific code problems is to have the device connected and in debug mode in Adobe ANIMATE, that way I can catch any Errors in the Output window.
For Example, if I am debugging and connected to Animate, the output window will throw errors like :
ReferenceError: Error #1065: Variable bg_storage is not defined.
at global/flash.utils::getDefinitionByName()
at Game/stageAdd()[/Users/**/Game.as:360]
Now I know exactly what the problem is and where to find it. I love errors like this.
My question :
If I didn't have a device connected to Animate in Debugging mode, is there a way to make the game detect any errors thrown and store them as a String, that way I can put up a big text block on the game of the error string and keep track.
or at least a way to log them some how?
Ex :
If an error is thrown, have that error text set as a String variable, then have a text box write out that String variable.
I hope that isn't too confusing. If I am going about debugging in a poor way, I would love to know what you guys do to keep track of errors without being connected to debug mode.
EDIT
I can see an approach is you to add an uncaughtErrorEvent event to each function to be able to catch these errors...
loadbar.uncaughtErrorEvents.addEventListener(UncaughtErrorEvent.UNCAUGHT_ERROR ... )
I am trying to make it so any error thrown in any part of the game will trace that error somewhere to a String value that I can call, so that I can see any error thrown during a play test session without being connected to debug mode.
Thanks!
Sure. There's a class intended exactly for that: https://help.adobe.com/en_US/FlashPlatform/reference/actionscript/3/flash/events/UncaughtErrorEvent.html See examples at the bottom of the page to listen to the right instances for that event.
You are also free go grab my own class that does the thing you want: https://bitbucket.org/thydmitry/ru.delimiter/src/2756fadd741a6d44276fde1701470daf24cebfa8/classes/ru/delimiter/utils/Log.as?at=default&fileviewer=file-view-default
You will need to add it to your project and then call in the main document class (in constructor, preferably):
Log.create(this);
Log.handleExceptions(this, true);

System.TypeInitializationException between two program in F#

I'm working on a project and I become always an Exception "TypeInitializationException".
I tried to give a string to a global string variable but it failed.
That's the code for the viewmodel and it failed on the second line
| {State = _}, ConsumablesClicked vm ->
Testtyp <- vm.TrackPosition.ToString()
That's on the other program
let mutable Testtyp = ""
I become this InnerException "Cannot read keys when either application does not have a console or when console input has been redirected from a file. Try Console.Read.".
"The type initializer for '.$BarcodeGenerieren' threw an exception.", that's the exception explication.
Has someone a Idea how solve this?
That exception indicates that some code is trying to call Console.ReadKey when the standard input for that process has been redirected (see e.g. Allowing redirection of StandardInput of a C# application when doing "Console.ReadKey"). The solution is not to call Console.ReadKey, but it's not clear from your description where this is actually happening (perhaps in the static constructor for one of your types?).
I found the solution after a lot of try and it was only, that I had a Console.Readkey in my code, that I forgot to delete.
I had before a console apllication and I transformed it to be a class.

.NET Exceptions: Does each exception type have its own message text?

We use ELMAH for our ASP.NET web app and I am stumped as to some of the exceptions we get. Some of these are:
System.FormatException: Invalid length for a Base-64 char array.
System.Web.HttpException: Unable to validate data.
System.Security.Cryptography.CryptographicException: Padding is invalid and cannot be removed.
I simply have no idea why they occur, but the end user apparently does not see them, so I want to ignore them and supress the emails. If I do this, I want to make sure that System.FormatException only uses Invalid length for a Base-64 char array. for its message text and not also some other message. If it did and I ignored it, I might be missing out on other exceptions that are thrown under System.FormatException. If that is the case, I'd have to check for the message text. That's not a problem, but I really don't like hardcoding strings in my app.
Update:
I tried this code:
try
{
throw new System.FormatException();
}
catch (Exception e)
{
Console.WriteLine(e.Message);
}
Console.Read();
And its message text is:
One of the identified items was in an invalid format.
This tells that the answerer is right and that exceptions should be ignored based on both exception and message text.
The exception's Message property is not useful to help you diagnose bugs in your code or problems with the user's configuration. This is also why you don't know why they occur. You must put more information in your email, particularly the exception's StackTrace property is crucial to help you find out exactly where the exception occurred. If an exception has an InnerException then you always need to know that one as well since it is typically the core reason another exception got triggered.
Simply use the exception's ToString() method to generate a better diagnostic to put in your email message.

How to debug a runtime stack underflow error?

I'm really struggling to resolve a stack underflow that I'm getting. The traceback I get at runtime is:
VerifyError: Error #1024: Stack underflow occurred.
at flash.events::EventDispatcher/dispatchEventFunction()
at flash.events::EventDispatcher/dispatchEvent()
at flash.net::URLLoader/onComplete()
This is particularly difficult to debug because when I run in debug mode it does not happen at all. It only happens when compiled as a release.
Does anyone have any tips on how to debug a Stack Underflow? Are have a clean explanation of what that means for Flash?
In case it helps, this error is occurring when I click a button whose handler makes an RPC call, which uses a URLLoader, an AsyncToken, and then invokes the set of AsyncResponder instances associated with the AsyncToken. With some server-side logging as well as some logging hacked into the swf, I know that the UrlLoader is successfully doing and GET'ing a crossdomain.xml file, is correctly processing it (ie: if I wreck it, I get a security error), and is also successfully completing the "load" request (the server sends the data). The underflow seems to be happening in the Event.COMPLETE listening/handling process (as is, of course, implied by the traceback as well).
mxmlc used = from flex_sdk_4.5.0.20967
Example player (I've tried a few) = 10.2.153.1
UPDATE: My specific problem is solved... but I'm leaving the question as-is since I would like to know how to generally debug such a problem, rather than just getting my specific solution.
In my code I had the following Application definition:
<s:Application height="100%" width="100%"
xmlns:fx="http://ns.adobe.com/mxml/2009"
xmlns:s="library://ns.adobe.com/flex/spark"
xmlns:mx="library://ns.adobe.com/flex/mx"
initialize="InitData();">
Note that the code is/was attached to the initialize event.
InitData() and relevant defintions are/were:
import classes.RpcServerProxy;
public var SP:RpcServerProxy;
public function InitData():void {
SP = new RpcServerProxy("http://192.168.1.102:1234");
}
When I switched the InitData() call to be on the onCompletion event instead of initialize (thanks J_A_X!), the problem goes away entirely. What seems to have been happening was that the Event.COMPLETE event handler (onComplete in the stack trace) was using the global SP object. Something about the release (vs debug) compilation must have been affecting the startup timing of the SP variable initialization. Moving the handler later to the onCompletion event resolved all issues.
As said above, I would still like to know what tricks/tools are available for debugging initialization issues like this.
UPDATE 2:
applicationComplete seems to be an even better event than creationComplete to put application initialization code. See this blog entry for some explanation, and and this video (around 4:25) by an Adobe Tech Evangelist for an example of simple "start of application" data initialization.
I got rid of this error by adding compiler argument:
-omit-trace-statements=false
Stack underflow basically means the compiler messed up.
You can use SWFWire Inspector to look at the bytecode of the event handler, if you want to know exactly how it messed up. You can also use SWFWire Debugger to see which methods were called, but in this case, you already knew where it was happening.
If you post the broken swf, I can give you more info.
Sean is right that to debug it you can look at the byte code, but that didn't sound appealing to me.
Based on my experience and research, it is often due to the presence of a trace statement that incorrectly gets compiled out in release mode, and generates invalid byte code. So, I would say to "debug" it, "Look for places where you are using trace. Try commenting them all out in the offending function and see if the issue goes away."
In my case, it was a trace statement as the first line of a catch block:
catch (e:TypeError) {
trace(e.getStackTrace()); //This line is the problem
throw new Error("Unexpected type encountered");
}
I found someone else with this exact issue here.
This code also leads to stack underflow only in release mode (flag -debug=false):
true && trace('123');
mxlmc flex sdk version 4.5.0.20967, flashplayer version 10.3.181.14 (linux).
Check your code for similar expressions.
This code caused me issues when I compiled a release candidate from flash builder 4.5
public function set configVO( value:PopupConfigVO ):void
{trace("CHANGING")
Resolved by inserting a space between the the trace and curly brace
public function set configVO( value:PopupConfigVO ):void
{ trace("CHANGING")
Hope this helps.
For people looking for the same problem, I just got this caused by a trace statement in the 'default' case of a switch statement. Commented out the trace, stack underflow resolved.
Interesting... I was getting this error with a SWF that I'd pulled off the web, an Away3D based graphics demo. At the time I was running this on the Tamarin VM rather than the actual Flash/AIR runtimes, so could stick a breakpoint on the "verifyFailed(kStackUnderflowError)" line and see what was happening.
The -Dverbose flag also helped find the culprit:
typecheck MethodInfo-1480()
outer-scope = [global]
[Object~ Object] {} ()
0:pop
VERIFY FAILED: Error #1024: Stack underflow occurred.
And looking at the ABC using SWFInvestigator, I found this:
var function(Object):void /* disp_id=0 method_id=1480 nameIndex = 0 */
{
// local_count=2 max_scope=0 max_stack=0 code_len=2
// method position=52968 code position=155063
0 pop
1 returnvoid
}
So there is an obvious issue where the 'trace' has been removed but the compiler has put a 'pop' in there: I wouldn't have thought this was needed as a trace call should presumably have been made via 'callpropvoid'?
Quite why this doesn't fail on AIR/Flash I don't know..
Anyway: looks to me like an ASC compiler problem i.e perhaps one of the ActionScript3 compilers had a fault with this - hence the workarounds that have been mentioned so far.
It's quite simple, and it doesn't have anything to do with spaces before or after brackets, trace commands or whatever else: it's just 1 really simple thingy:
DO NOT LOOP EMPTY!
Meaning, while developing, we all //comment some lines sometimes, and when that results in
for (...) {
// skip for now
}
the compiler gets :
for(...){}
and that my good friends, is something the compiler doesn't like!
so, NO empty loops, and you're on your way again...
Happy hunting,
P.
I had the exact same problem, but in my case the cause of the problem was a trace statement in a place where the compiler didn't expect it to find it, right after a package declaration at the beginning of the class:
package utils
{
trace ("trace something here");
And that's why compiling in debug mode removed the problem.

lstrcpy() causing exceptions in visual C++ code

I used a MFC virtual list control to enhance the performance and I handle GetDispInfo(NMHDR* pNMHDR, LRESULT* pResult) to populate the ListCtrl. The relevant code in that method is as follows:
if (pItem->mask && LVIF_TEXT)
{
switch(pItem->iSubItem)
{
case 0:
lstrcpy(pItem->pszText, rLabel.m_strText);
break;
case 1:
sprintf(pItem->pszText, "%d", p.o_Value);
break;
default:
ASSERT(0);
break;
}
}
Here, when I use lstrcpy(),when I'm srolling down/up, I get a whole lot of exceptions saying First-chance exception at 0x7c80c741 in test_list_control.exe: 0xC0000005: Access violation writing location 0xb70bf2ac. These messages appear in the debug output. But the program doesn't crash. Can anyone please explain what the matter here and how should I overcome that??
rLabel is a CLabelItem which I have declared earlier.
Thank you!
If all you see is the first chance exception thing, stop worrying. See for example Link but you can find similar pages all over the place (mostly from 5-10 years ago.) It means some code threw and the exception was caught and dealt with. I see this in MFC apps some times. As the blog entry says
First chance exception messages most
often do not mean there is a problem
in the code.
I would wait until you see actual errors before getting worked up about this one.
I think you should check if buffer that is pointed by pItem->pszText is large enough to hold rLabel.m_strText. Or if rLabel.m_strText is correct null terminated string. For me this looks like writing uninitialized memory. Use the debugger to check this.