I noticed that i can use Xojo exceptions to “simulate” raising and and handing (catching) events, when a need arises to “call back” with results. In a sense I can defined two kinds of exceptions. Real exceptions and “notifications”.
Defining a “notification event” is simple:
define a notification object
wrap the caller in e try block, and catch the notification in the caller
raise “exception” with notification object
read at the caller side any data supplied in the notification object
This is instead of defining an event within the scope of the callee (which is not always possible, events can’t be defined on modules, so a method in a module can not raise its own custom event), which needs to the following steps:
defining an event
defining an event handler
defining an event handing method
defining an AddHandler somewhere, and ensuring it gets called before the event is needed
raising the event at the callee
Best I think would be a with events keyword that would reduce the above to:
defining events for a callee
defining with-events clause in the caller
defining the event routine associated with a callees events
raising event within the callee
I think the withevent (third option) and “notification event” (first option) are essentially equivalent solutions, likely, with the same kind runtime overhead. However, the “notification” option, seems more flexible, since the notification must not be dealt with by the caller, and can get escalated to the caller of the caller … which i think is interesting.
I’d love to have a channel here dedicated to Xojo programming techniques and architectures.
Have a look at the observer example on how to implement a notification system (it is in the Example Projects/Design Patterns folder.
Personally I’d go with delegates.
What I don’t like about the observer pattern, is that its not “light weight” – as a programmer, you have to set up a lot of things, in different places, before it works. This makes it harder to understand and debug. Also, observer patterns can lead to very hard to find bugs, when call back takes place, with unfinished processing in parts of the logic.
Exception handing has a key benefit that the call stack is aborted and a new “program entry point” is established.
I like getting at the reasons for doing things. So, even if i don’t like, say, using the observer pattern, if its the best option for a particular job, then I would choose it …
You only need to set this up one time. With modern programming paradigms observer sometimes makes a bit of spaghetti code.
Also exceptions are relatively slow. Once upon a time I found out that checking for duplicates in a database was slow. Replacing the SQL with an exception made things even slower. YMMV
I noticed that i can use Xojo exceptions to “simulate” raising and and handing (catching) events, when a need arises to “call back” with results. In a sense I can defined two kinds of exceptions. Real exceptions and “notifications”.
[/quote]
I’d not do this
Exceptions are slow
They are expensive and are really non-local GOTO’s
Exceptions are really the antithesis of events. Events propagate forward. Exceptions propagate back up the stack. It’s difficult to understand what problem you’re trying to solve using exceptions.
Thanks for your question. Here is the problem I am trying to solve.
I am trying to keep to a specific architecture that separates between the Domain methods and the UI dialog management and event handing. The separation is done via a Dialog Manager that mediates from the UI to the Domain. However, sometimes I need the domain to notify the Dialog Manager, such as to display some domain relevant failure. I do not want the Domain to “know” about the Dialog Manager.
So, I need an “event” to be raised in the Domain that then gets processed by the Dialog Manager. So far, I also do not want processing to continue in the Domain; so raising an “notificaiton” exception is actually quite helpful in aborting any further processing in the domain.
Is your dialog synchronous or asynchronous? For an async dialog you need a notification. But for a simple synchronous one I’d say that this is overkill. You have something like
Do you really want to abstract this? And if you do want to abstract it then do it at the beginning and afterwards let the domain take over. I had to do something similar for the file-or-folder-selection dialog from Cocoa.
Its asynchronous. The reason why its asynchronous is because I let database constraints detect domain constraint violations. And, I don’t want database code to be called in the UI event handler. So, only when an exception is detected, then a dialog can be shown.
I am now thinking to change that, and create domain method that tests for domain constraint violations before doing an action. This would allow me do synchronous dialogs. I am not sure which approach is “better”. The latter one duplicates constrain checking, so perhaps its not such a good idea.
