Bug180 Editing
To reproduce: - open server (bin/berlin &) - open daVinci (bin/daVinci) - select polygon tool (triangle symbol) - click in drawing window
This seems to be fixed now, but was this a change to the server that solved it? If it was a change to daVinci then this bug should not be closed: it signifies a crash-susceptibility in the server.
this is a pretty important issue, which can be especially well tested with scripts that don't do static type checks: the server has to be prepared for all kinds of error conditions, such as incorrect arguments (especially out and return parameters). Making the server exception safe is a huge task...
From SF bug <https://sourceforge.net/tracker/index.php?func=detail&aid=415289&group_id=322&atid=100322>: Command:execute and client exceptions Reproduce: 1. Create a client that throws an uncatched exception in the implementation of Command::execute. 2. Hand that command to the Berlin server, e.g. through ToolKit.Trigger. 3. Trigger the exception Actual result: The exception goes via CORBA over to the Berlin server process, which doesn't expect it, doesn't catch it and bails. Expected result: Berlin server process protects itself about unexpected exceptions from clients. Additional Comments: Bug is not only in WidgetKit, but also ToolKit and other kits (IIRC). Fix: I have a fix. I just wrap execute call in the server (which might go to clients) with try ... catch(...) .... -- Date: 2001-04-11 05:41 Sender: benb I fixed this by wrapping the execute() calls in the server in |try {<..>} catch (...) {}| (the dots in catch(...) are literals, not a placeholder). Better would be to just catch the CORBA exception UNKNOWN (which the ORB throws in this case, per CORBA spec version 2.4.2, page 4-53 and my testing). It's just a few calls in the server, e.g. in Toolkit.TriggerImpl, Dragger, Stepper and in WidgetKit.Button, IIRC. Patch (for checkin) on request. -- Date: 2001-04-11 05:43 Sender: stefan actually, the exception that is thrown by the server ORB is of type CORBA::UNKNOWN (since it can't marshal a type that is not declared in IDL). We need to define a general policy about what exceptions to catch where; and of course we need to write excption safe code.
I've just been examining how this currently works (or doesn't) for Commands. It is not entirely perfect, but only a TriggerImpl and Dragger take a Command_ptr. Even so, I created a wrapper class which handles Command destruction (_command->destroy), reassignment and execution, with appropriate exception-handling for each. Currently it catches all exceptions, but we could perhaps add a template mechanism for dealing with special cases where specific exceptions may want to be let through - but I haven't seen a need for this yet. A wrapper class is useful as it handles all the exception-catching, but it could also act as a hook into a connection-tracking system (eg. rather than setting commands to _nil when we fail to connect to clients, we might disconnect the clientcontext entirely, or whatever - dependent upon the connection-tracking policy). Having it in one class allows it to be a centralised place for making changes like these. In addition, if we were to have a class like this, then it also acts as an appropriate place to call AMI functions, or similar. We could maybe consider similar versions for Graphics, Observers, ... in addition to Commands.
there seems to be agreement that this bug should be closed, even though the server is far from what is usually referred to as 'exception safe'. Let's create a task for this to remind people to look into this further, but there is no sense to it being a single bug report.
Assign to stefan as he seems to have been the one closing this bug.
ivHrmK <a href="http://hbfadisdwtqf.com/">hbfadisdwtqf</a>, [url=http://phndtuignnof.com/]phndtuignnof[/url], [link=http://yqtmxrzfkpmh.com/]yqtmxrzfkpmh[/link], http://xmqaxqkzqpzw.com/
not logged in
register
Home