On bpls and assistants

delphi package - automated exception handling

On bpls and assistants

Postby altxt » Thu Nov 24, 2016 4:51 pm

Hi madshi,
I just started using madExcept and got a couple of questions.

1. My code is a project group with projects nested inside. One of them compiles to an executable, the others are bpls and get loaded into the process of the exe project at runtime. How do I use madExcept to get stack traces for the entire code base? Do I need to enable madExcept (via Project menu) in all projects, or enabling it in exe only is enough?
- If exe is enough, where does madExcept get the symbol information for the bpls?
- And if all the bpls need to have madExcept enabled, do they need to include (use) madExcept units, or do they only need the patching by the IDE plugin or the command-line tool? Can they inherit madExcept's settings from the exe?

2. I need to let the user suppress repeat exceptions. I could not find a way to add logic & controls to madExcept's native exception box, so I used an 'assistant' and a custom form inside it instead. This works fine, I added a checkbox and wrote a test to only show the form if that particular exception was not seen earlier by the process. However, I could not find a way to close the form and the assistant from code - their ModalResult properties are read-only and there is no Close() or similar method in the docs. So a user needs to first press one of the custom buttons (I've hidden the default Continue/Skip/Abort buttons since they don't make much sense for a single form) and then click X to close the form. Not very friendly... Can you help me with this?

That was actually more than two questions, sorry )) And thanks for making madExcept!
altxt
 
Posts: 10
Joined: Thu Nov 24, 2016 3:47 pm

Re: On bpls and assistants

Postby altxt » Fri Nov 25, 2016 6:39 am

On my second question, PostMessage(GetActiveWindow(), WM_CLOSE, 0, 0) seems to work just fine
altxt
 
Posts: 10
Joined: Thu Nov 24, 2016 3:47 pm

Re: On bpls and assistants

Postby madshi » Fri Nov 25, 2016 10:33 am

I suppose you're using the RTL and VCL runtime packages in your EXE and in all your BPLs, so none of them have the RTL/VCL linked in? Or do you have the RTL/VCL linked into the EXE, and only the BPLs use the RTL/VCL BPLs?

Generally my suggestion would be to link madExcept into the EXE by checking the 3 "linker options" checkboxes here:

http://help.madshi.net/madExceptSettings1.htm

For your BPLs you will most probably only need to let madExcept add the function names and line numbers to your BPLs. You can do that by just checking "link in function names and line numbers" and leaving the other 2 linker options unchecked.
madshi
Site Admin
 
Posts: 9412
Joined: Sun Mar 21, 2004 5:25 pm

Re: On bpls and assistants

Postby altxt » Sat Nov 26, 2016 2:12 am

Thank you, that's exactly what I was looking for. And yes, I am using runtime packages in all projects.
altxt
 
Posts: 10
Joined: Thu Nov 24, 2016 3:47 pm

Re: On bpls and assistants

Postby altxt » Mon Nov 28, 2016 12:36 pm

Another question on bpls.
madExcept seems to treat exceptions that cross bpl boundaries as unhandled, even though there is a handler in another module. I attach a demo project group. With madExcept disabled, the standard exception box never shows up, as all exceptions are handled (handlers use ShowMessage() for notification). With madExcept enabled in exe, the exception that is not handled inside the bpl and should be caught in the exe produces madExcept's exception box.
I am using Delphi XE6 Update 1 and madExcept 4.0.16.
Is there a way to restore the usual flow of exceptions? I'd really like to process them in other packages than they were originally thrown from.
Attachments
bpl.zip
(67.24 KiB) Downloaded 33 times
altxt
 
Posts: 10
Joined: Thu Nov 24, 2016 3:47 pm

Re: On bpls and assistants

Postby madshi » Tue Nov 29, 2016 2:00 pm

Can you please upload a bug report of this situation? Might make it easier for me to see what's going on than to try to compile a multi-project demo project. Thanks!
madshi
Site Admin
 
Posts: 9412
Joined: Sun Mar 21, 2004 5:25 pm

Re: On bpls and assistants

Postby altxt » Wed Nov 30, 2016 7:05 am

Sure, here it is
Attachments
bugreport.txt.zip
(5.68 KiB) Downloaded 37 times
altxt
 
Posts: 10
Joined: Thu Nov 24, 2016 3:47 pm

Re: On bpls and assistants

Postby altxt » Mon Dec 12, 2016 5:58 am

Any news on the subject? Madshi, were you able to reproduce the problem? Please tell if you need further information.
altxt
 
Posts: 10
Joined: Thu Nov 24, 2016 3:47 pm

Re: On bpls and assistants

Postby madshi » Tue Dec 13, 2016 6:35 pm

There's a special handler in madExcept that hooks into the "LoadPackage()" function and activates madExcept for all unhandled crashes that happen during LoadPackage(). The main purpose of this is to make such crashes visible because otherwise they might get lost somewhere in some Delphi versions.

There's a relatively easy way to work around this issue: You can create a little exception handler like this:

Code: Select all
procedure IgnorePackageLoadExceptions(const exceptIntf: IMEException; var handled: boolean);
begin
  if exceptIntf.Source = esInitializePackage then
    handled := true;
end;

initialization
  RegisterExceptionHandler(IgnorePackageLoadExceptions, stDontSync, epQuickFiltering);
end.

Hope that helps?
madshi
Site Admin
 
Posts: 9412
Joined: Sun Mar 21, 2004 5:25 pm

Re: On bpls and assistants

Postby altxt » Wed Dec 14, 2016 8:04 am

Hooking into package load at esInitializePackage works, but you sample is suppressing the exception. How can I let it go to the appropriate try/except handler? I tried
exceptIntf.CallHandlers:=true;
and
exceptIntf.ShowSetting:=ssNothing;
but the handler did not fire.
altxt
 
Posts: 10
Joined: Thu Nov 24, 2016 3:47 pm

Re: On bpls and assistants

Postby madshi » Wed Dec 14, 2016 8:16 am

The way the code is currently written, madExcept always catches and handles the exception, so there's no way to pass it to the original handler, unfortunately. However, I suppose that your call to LoadPackage should fail in this situation, so if all else fails, you could check the result of LoadPackage and if it failed, you could manually raise another exception right after LoadPackage. Does that help?

I'm not sure what the appropriate try/except handler is doing. Can you maybe just copy that code to the exception callback I suggested in my previous comment?
madshi
Site Admin
 
Posts: 9412
Joined: Sun Mar 21, 2004 5:25 pm

Re: On bpls and assistants

Postby altxt » Wed Dec 14, 2016 11:17 am

I just tried it, and, unfortunately, it does not work. LoadPackage() can only fail if the nested LoadLibrary() fails, otherwise it returns a module handle regardless of what happens in initialization sections of units packaged into the bpl (or an exception, but madExcept swallows it). I guess I'll have to move the throwing code from initialization to a global function (basically, it checks whether the end user has permission to use the package).
The good news is that exceptions thrown by "normal" methods in packageds units are caught by a handler in the exe just like they should be, so the problem is not as severe as I initially thought.
Thanks for your help!
altxt
 
Posts: 10
Joined: Thu Nov 24, 2016 3:47 pm

Re: On bpls and assistants

Postby madshi » Wed Dec 14, 2016 11:25 am

So you can work with the way it currently is?
madshi
Site Admin
 
Posts: 9412
Joined: Sun Mar 21, 2004 5:25 pm

Re: On bpls and assistants

Postby altxt » Thu Dec 15, 2016 9:24 am

Yeah, though it took some time to refactor code in a way that does not introduce unnecessary coupling. Luckily, the framework used in the project provided a means to that.
altxt
 
Posts: 10
Joined: Thu Nov 24, 2016 3:47 pm


Return to madExcept

Who is online

Users browsing this forum: No registered users and 1 guest