Dear Friends,I am reading one text file and writing that content in one BasicEditField .If i try to type some thing in the editfield after writing the content of file, then it throughs a uncaught exception like "net_rim_plazmic_flint (126) is not responding,process terminated "can u pls tell me what is this exception and how to solve this exception give some idea.
regards,
s.kumaran.
This usually indicates that a Listener called by the the event thread is taking too long to return, or not returning at all. Any protracted processing, or methods that block waiting for an asynchronous event, can't run on the event thread.
Have a look at this post.
Related
My code crashed, and the following line gets highlighted in red. But some crash handle function should continue. How can i debug this crash handle function:
NSSetUncaughtExceptionHandler(&HandleException);
The error that you're generating doesn't result in an Objective-C exception, so exception handlers aren't going to be invoked for it.
If you're trying to test exception handling, you should replace your method code with a throw. If you're trying to test for handling of that specific code, you should create a signal handler for the error that's cut off by your screen shot. (SIGABRT, SIGSEGV, ...?)
I am creating csv file and writing a data to that file using writeData method of NSFileHandle. Apple mention method raises exception if no free space is left. My question is that how would i handle exception in swift 1.2. And what best possible way to handle memory limit issue check before writing to file?
Swift doesn't offer exception handling. Yes, you can 'install' your own exception handler, but you are still not able to recover from an exception. What Swift 2 provides for you is error handling (not exception handling), see apple docs about do / try / catch
func writeData(_ data: NSData)
If the receiver is a file, writing takes place at the file pointer’s current position. After it writes the data, the method advances the file pointer by the number of bytes written. This method raises an exception if the file descriptor is closed or is not valid, if the receiver represents an unconnected pipe or socket endpoint, if no free space is left on the file system, or if any other writing error occurs.
I'm struggling with exception handling inside my Datasnap REST Service (Delphi XE3 but also tried with Delphi 10 Seattle). I have written half a dozen Windows Service over the years and I always include a TApplicationEvents component so that I can log any Application Exceptions to the Windows Event Log.
However, this behaviour is not happening with a Datasnap Service. The TApplicationEvents.OnException event never gets fired, so I assume something else is eating the exception and handling it before it gets here.
The exception is displayed in the web service method's result, which is fine because it means I can at least display something on the client side, but I'd also like to catch it before then so that I might be able to handle different exceptions server-side.
The only consistent way I have managed so far is to wrap each individual method in a try..except block, and handle the exception in each method, before re-raising the exception. However, with a Web Service of 20 methods and growing, this isn't really going to scale up.
I have also tried implementing the OnError, OnTrace and other events of the some of the Datasnap components (TDSServer, TDSHTTPService, TDSTCPServerTransport, etc.) but these never seem to get fired either.
Has anyone come across anything like this, please?
Tl;Dr: it's not implemented in a usable fashion (in 10.1 Berlin).
I came across the same problem and after reading through a lot of source, I found no practical solution.
So an exemplary (my) StackTrace would look like this:
MyClass::MyServerMethod()
/* skipping some funny unimportant RTTI/TValue handling here */
System::Rtti::TRttiMethod::Invoke
Dsreflect::TDSMethod::Invoke(TObject, TDSMethodValues)
TDSServerConnectionHandler::DbxExecute(const TDBXExecuteMessage)
TDSServerCommand::DerivedExecuteUpdate
TExecuteCallback
TDSService::Execute(const string, const TRequestCommandHandler, TExecuteCallback)
TDSService::ProcessRequest(const string, const TRequestCommandHandler, TExecuteCallback)
TDSRESTService::ProcessREST(const string, const string, const TArray<Byte>, const TRequestCommandHandler)
TDSRESTService::ProcessGETRequest(const string, TStrings, TArray<Byte>, TRequestCommandHandler)
TDSRESTServer::DoDSRESTCommand(TDSHTTPRequest, TDSHTTPResponse, string)
TDSRESTServer::DoCommand(TDSHTTPContext, TDSHTTPRequest, TDSHTTPResponse)
Dshttpwebbroker::TDSRESTWebDispatcher::DispatchRequest(TObject, Web::Httpapp::TWebRequest, Web::Httpapp::TWebResponse)
Note: This depends entirely on your usage of DataSnap. In the above case requests are passed into the DataSnap API through TDSRESTWebDispatcher (comming from TIdCustomHTTPServer).
Every Exception raised in a ServerMethod will end up in TDSService::ProcessRequest.
In this procedure every Exception is caught and ONLY its Message is added to a TRequestCommandHandler->CommandList.
Further down the Message is written as JSON/DBX command to the output.
So we can never handle the Exception Object and access the StackTrace or other information. So this alone is unacceptable and has to change
The good news is, that this procedure is virtual and can be overwritten. The bad news is, that in the example above you would have to extend TDSRESTService with your own ProcessRequest procedure (including your errorhandler), TDSRESTServer with own DoDSRESTCommand (in there the TDSRESTService is created in a monstrously large procedure) and TDSRESTWebDispatcher (depending on your usage).
My personal recommendation is to don't use DataSnap.
Note: At the point of writing this, I haven't found any invoke of the OnError event.
Solution found, see my comment below
D5, odbc to mysql database
This code:
with QryCmdPerf do begin
Close;
ParamByName('ACCTID').AsInteger:= AcctId;
ParamByName('FROMDT').AsString:= MySQLDate(FromDt);
ParamByName('TODT').AsString:= MySQLDate(ToDt);
Open;
first;
try
edit;
FieldByName('PnL').AsFloat:= 97979;
ApplyUpdates;
except
close;
end;
end; // with
(specifically the "ApplyUpdates") causes a popup to appear with the text "Update Failed" if the PnL field already has the value 97979, evidently because of this code:
procedure TUpdateSQL.ExecSQL(UpdateKind: TUpdateKind);
begin
with Query[UpdateKind] do
begin
Prepare;
ExecSQL;
if RowsAffected <> 1 then DatabaseError(SUpdateFailed);
end;
end;
in DBTables.pas. Anyway, I want to be able to issue ApplyUpdates, and not have to worry about a popup if it doesn't do any updating. But if "try...except" doesn't work, what will?
TIA
You're confusing the dialog displayed by the debugger with a dialog displayed by your program. Please see this article I wrote a few years ago:
Why do I continue getting error messages even after I have written an exception handler?
It describes several ways to avoid the debugger interfering:
Use "advanced breakpoints" to temporarily disable the debugger around the code that throws exceptions.
Configure the debugger to ignore certain exception types. (Read the debugger's message more carefully to see exactly what exception class you're dealing with.)
Configure the debugger not to interrupt on any exceptions.
Turn off integrated debugger entirely.
The short answer is, you have to set up an eventhandler for OnUpdateError or no amount of "try...except" blocks will block the popup. The long answer is it appears to be a bug with odbc. The repro is here: http://www.codeupload.com/3919 for anyone who wants to take a look at it. You can skip the MySQL stuff, any odbc database will do.
There are two things that can be going wrong here.
Option 1
First, some "very bad code" may be short-circuiting the unwinding of the call stack on exceptions. E.g. ApplyUpdates or one of its child routines may also have a try...except block that calls Application.HandleException directly.
To test this, if you put a breakpoint on QryCmdPerf.Close, do you reach it?
If not, then Application.HandleException (or worse Application.ShowException) has been called directly.
Solving this requires a custom exception handler hooked to the Application.OnException event. You may have to set temporary state to know when this particular exception can be ignored.
Yes it's messy, that why calling Application.HandleException directly, is "very bad code".
Option 2
If you do reach the breakpoint, but the exception is being raised again, then it should be a lot simpler to solve.
The Close method is probably attempting to save any pending changes, so is effectively applying the updates again. Rather than simply closing the data set, call CancelChanges or equivalent.
Background
We have a problem that sometimes the grid in Devexpress raise exception
"Raised EConvertError: Cannot assign a nil to a TFont".
But to trace the real cause of this we have changed Font in cxEdit to be a public property instead with a get and set method. Here I want to log the callstack.
My question
Normally JCL is used to log callstacks when exceptions appear. But how can I log the callstack without using raise exception and show a dialog for the user about this ?
I have found the lines:
var
GlobalStackList: TJclGlobalStackList;
in JclDebug but I fail to use it. If someone have a example how to get the callstack I would be happy.
Regards Roland Bengtsson
This answer shows how to do it with JCL by calling JclCreateStackList.