Note that there are some explanatory texts on larger screens.

plurals
  1. PO
    text
    copied!<p>See <a href="http://www.blueskyline.com/ErrorPatterns/A2-LongshawWoods6.pdf" rel="nofollow noreferrer">Patterns for Generation, Handling and Management of Errors</a></p> <p>From the Split Domain and Technical Errors pattern</p> <blockquote> <p>A technical error should never cause a domain error to be generated (never the twain should meet). When a technical error must cause business processing to fail, it should be wrapped as a SystemError. </p> <p>Domain errors should always start from a domain problem and be handled by domain code. </p> <p>Domain errors should pass "seamlessly" through technical boundaries. It may be that such errors must be serialized and re-constituted for this to happen. Proxies and facades should take responsibility for doing this. </p> <p>Technical errors should be handled in particular points in the application, such as boundaries (see Log at Distribution Boundary). </p> <p>The amount of context information passed back with the error will depend on how useful this will be for subsequent diagnosis and handling (figuring out an alternative strategy). You need to question whether the stack trace from a remote machine is wholly useful to the processing of a domain error (although the code location of the error and variable values at that time may be useful)</p> </blockquote> <p>So, wrap the hibernate exception at the boundary to hibernate with an unchecked domain exception such as a "UniqueUsernameException", and let that bubble up all the way to the handler of it. Make sure to javadoc the thrown exception even though it isn't a checked exception!</p>
 

Querying!

 
Guidance

SQuiL has stopped working due to an internal error.

If you are curious you may find further information in the browser console, which is accessible through the devtools (F12).

Reload