transactions - Grails/Groovy : custom Transactional exceptions -

sorry have updated question, because quite trivial question , should have highlighted actual concerns on here.

thinking it, advantage in logs or sake of tracibility having such custom exceptions of use..

i have put demo project grails: https://github.com/vahidhedayati/test-transactions ported on java example found here: https://today.java.net/pub/a/today/2006/08/31/jotm-transactions-in-spring-and-hibernate.html

i still need work on @ moment trying find best approach/practice since don't think content of groovy exceptions clean should (a little more java looking groovy)

example below source code

package com.example.exception  class flightnotfoundexception  extends travelexception {      public flightnotfoundexception(string message) {         super(message)     }      public flightnotfoundexception(exception e) {         super(e.getmessage())     }  } 

is correct way of doing exception class in groovy ?

source code

class flightmanagerservice {  @transactional def reserveflight(bookingrequest bookingrequest) throws flightnotfoundexception { ... } 

it gets used in service , each of these services throws custom exception said can see advantage trace later or exception.. necessary mean simple log.info/error report service failed or throwing exception anyways..

so rather try think should mess around still worth clearing find better practice. thinking grails trainsaction video should remove try catches , possibly replace throwable service actions :

new domainclass(name: "something", value: 'another').save()         throw new runtimeexception("issue saving domainclass") 

any input appreciated

updated add

after conversating joshua

@transactional  def something() {      domaininstance.save(failonerror: true, flush: true) } 

should suffice without fancy work.. (will experimentation when , update git project)

the problem using exceptions non-exceptional cases. trying use them logic, , business rules. while common, it's common abuse of exceptions in general.

in best case should strive have code not use exceptions flow control. should used in cases exceptional (e.g. not expected behavior) occurs.

however, said, if continue on want make sure don't include stack traces. grails has huge stack traces , filling them in in exceptions going huge performance hit. can avoid doing adding following custom exceptions:

/** * don't fill in stack trace because want things faster. **/ @override public throwable fillinstacktrace() {     // nothing     return }