Hello guys
Hello guys,
Does anyone of you know how to make #DB exception handled only by the application and NOT by Delphi debugger ?
When #DB exception occurs, if the application is under Delphi debugger, this one takes control and handles the error. If not under debugger, application takes control and handles the error if vector exception handler was already registered. I want to let my app handles #DB whenever it's under debugger or it's in release mode. In that way my app handles the error at the first place then it decides whether to notify Delphi debugger or not.
Does anyone of you know how to make #DB exception handled only by the application and NOT by Delphi debugger ?
When #DB exception occurs, if the application is under Delphi debugger, this one takes control and handles the error. If not under debugger, application takes control and handles the error if vector exception handler was already registered. I want to let my app handles #DB whenever it's under debugger or it's in release mode. In that way my app handles the error at the first place then it decides whether to notify Delphi debugger or not.
Tools->Options->Debugger->Language Exceptions
ReplyDeleteAdd your exception to the ignore list
But you have no control over the Debugger. You can't decide "notify them".
ReplyDeleteWhy notify? If the debugger doesn't handle it, the application does. So if it is ignored by tge debugger, the apllication will always handle it.
ReplyDeleteNormally I want my debugger to stop when my database exceptions occur because it's so rare that I need to investigate it. If you have a scenario that differs then just ignore that exception for a while. The dark pattern that emerges is that you as a developer become farther and farther out of touch. You may assume some other queries are working but they are not working, and you didn't find out.
ReplyDeleteWarren Postma That's what the "Continue" button is for. So if a DB exception is rare do not ignore it. Just investigate or click continue.
ReplyDeleteWhat really seems is that you have a problem that affect the whole program or a routine that is called frequently. And instead of solve the problem, you've developed a exception handler to treat of ignore it.
ReplyDeleteNow you need to solve a new problem: Which exceptions shall be managed and which not, by this exception handler?
As you can see, this is an eternal way of problems. You are going to need solve a new pile of problems every day.
I think you should treat of solve the initial problem. Is the short way!
Good luck!
(I'm in a supposition. If I'm in a mistake, I wait you can excuse me. Thanks).
Alexander Benikowski Warren Postma Delphi debugger uses #DB exception in order to make breakpoint. Thus #DB exception will not get ignored by the filter ! Now let me explain what I mean by notifying Delphi debugger. I have my own #DB exception ... when an error occurs my handler get executed and recognizes the error (#DB) . If it was from the Delphi debugger it will dispatch (notify) Delphi debugger so the debugger can break (user breakpoint). If it was my (#DB) ... Only my app get access to it and it will handle it without notifying Delphi debugger. As you see that's not something I can solve by adding exception to the ignore list.
ReplyDeleteJuan C. Cilleruelo Ah no, I don't have any internal problems that cause #DB exceptions! Recently when I worked on DebugEngine, I learned a lot about "SEH". So I was wondering if I could combine between SEH and Debug BP to introduce a new way for hoking in the next Delphi Detours Library version (v3). I did some draft example and I got a very encouraging results. However my tests for now work only when compiling for release mode. In order to make the library works under Debug mode I need to make Delphi debugger ignore my #DB exceptions.
ReplyDeleteThat sounds potentially scary. I wouldn't want to use your code for this reason. The existing ways of doing hooks are better than your way.
ReplyDeleteWarren Postma I said I'm going to INTRODUCE and NOT REPLACE the legacy hook ! There is a lot of situation when this way will be better than the legacy hook. And by using this way It will be possible to NOT SUSPEND THREADS ! Rather than suspending threads on legacy hooks... threads will enter to a lock process when accessing the hooked function. There is nothing to worry about ! ... I know it's a little bit hard to understand but you will understand everything once I set up things correctly.
ReplyDeleteI know you're not going to replace it, but I'm a little scared of any attempt to be this clever. Even the wisest among us cannot always see all ends.
ReplyDeleteWarren Postma Believe me there is nothing to worry about ( when you insert a breakpoint into your app at line xxxx ... does that make you scary ? of course not !!) and it's the same for DDL ... When legacy hook will not be possible (let say mapping process failed or hoking very small routine,...) here in such situation you may continue hoking using the new way. That's it ... nothing will get changed xD.
ReplyDeleteMahdi Safsafi "Believe me there is nothing to worry about"
ReplyDeleteSuch reassuring words...
/sub
ReplyDelete