Hi All,
I have an exception called: AlreadyExistApplicationOrFormNameException. The code is like this: [aBoolean ifFalse: [self doSomething] ifTrue: [AlreadyExistApplicationOrFormNameException signal]. ] on: AlreadyExistApplicationOrFormNameException do: [:ex | (ObjectLogEntry info: 'Rejected Form Save' object: ex) addToLog. ^System commit]. self doMoreThings. The System commit is because Seaside will abort the transaction when an Exception is thrown preventing the log entry to be saved. For now everything is OK. But i want to move this code to #defaultAction in the Exception: defaultAction "When this exception happend nothing is done (just resume the execution). Seaside will abort the Request and the Form will be not stored in the repository" ^[:ex | (ObjectLogEntry info: 'Rejected Form Save' object: ex) addToLog. System commit. ex resume]. But there is nothing in the ObjectLogEntry. Any idea what is wrong with this ? (i have read chapter 13 "Handling Exceptions" but not idea why the entry is not saved) Regards, Bruno |
Hi,
This is working as expected with default handler: AlreadyExistApplicationOrFormNameException addDefaultHandler: [:ex | Transcript nextPutAll: 'Error', String lf. ex resume]. (1=1) ifTrue: [AlreadyExistApplicationOrFormNameException signal]. "this trigger the output in the Transcript" Not sure why using #defaultAction is not working... Regards, Bruno |
Hi,
Now #defaultAction is working i just put aBlock in default action which is wrong. With: defaultAction Transcript nextPutAll: 'Error', String lf. Now "the three line of defense for an exception" are working... Regards, Bruno |
In reply to this post by BrunoBB
Hi Bruno,
A quick question regarding your statement below:
Seaside itself does not abort the transaction when an error is thrown. Did you implement the abort behavior yourself in a custom WAErrorHandler subclass? Mind that each request is a single transaction, and if you do transactions yourself within the request, the ‘standard’ abort behavior of a Seaside request is broken. You also need to take into account that the commit you trigger might not be possible because of commit conflicts. If you do not handle these, your system might break because a gem gets stuck in a commit conflict. Doing transactions within the ‘request transaction’ of Seaside does require you take that into account, so I just wanted to make sure you did that. Johan _______________________________________________ Glass mailing list [hidden email] http://lists.gemtalksystems.com/mailman/listinfo/glass |
Hi Johan,
thanks for the answer. The code above it was a test i do not have any "System commit" in my application. I do not know why but i assumed when an exception is thrown Seaside abort the transaction. There is no WAErrorHandler subclass in my app. Thanks for the information i think the problem was my (test) implementation of the exception handler. Everything is clear now :) Regards, Bruno |
In reply to this post by BrunoBB
On Wed, May 4, 2016 at 1:50 PM, Smalltalk <[hidden email]> wrote:
Yes, I also thought that!! I don't know why either hahahahah.
_______________________________________________ Glass mailing list [hidden email] http://lists.gemtalksystems.com/mailman/listinfo/glass |
Free forum by Nabble | Edit this page |