There, now that that got your attention, let me elaborate on the
intention of these types.
Basically, they are a semantically richer way of expressing common
failures when developing backend-servers.
Furthermore, these exceptions being part of the core of the application
—by reading this file— you have not gauged their full potentiality, yet.
The intention is to give richer interpretations to these "common failures"
in other busymachines-commons module than could be done to the likes
of Throwable.
The reason why there is a trait FailureMessage, and some types
that extend Exception is that the potentiality of these types can
be achieved either through a monad stack approach to building applications,
or to a more vanilla scala approach, respectively.
These definitions are also quite flexible enough to allow multiple styles of active
development:
1) The quick and dirty, "better than RuntimeException" style. Basically,
you just wind up using the default constructors on the companion object,
or the companion object itself
//I know I am in the middle of my domain problem, and I know that here//I can fail because "I did not find something", so I just quickly use:
option.getOrElse(throw NotFoundFailure)
option.getOrElse(throw NotFoundFailure("this specific option, instead of generic"))
This style should be kept just that, "quick and dirty". After the first iteration
of the implementation these failures should be replaced by the ones in style 2)
2) The long term style. Where you subclass NotFoundFailure into a more meaningful
exception specific to your problem domain, supply some context via the parameters,
and assign it an (preferably) application-wide unique FailureID.
object RevolutionaryDomainFailures {
caseobject CannotBeDone extends FailureID { val name = "rd_001" }
//... and many others
}
caseclass SolutionNotFoundFailure(problem: String) extends NotFoundFailure(
s"Solution to problem $problem not found."
) {
overridedef id: FailureID = RevolutionaryDomainFailures.CannotBeDone
overridedef parameters: Parameters = Map(
"problem" -> problem
)
}
object Main {
//...
solutionToPVSNP.getOrElse(throw SolutionNotFoundFailure("P vs. NP"))
solutionToHaltingProblem.getOrElse(throw SolutionNotFoundFailure("Halting Problem"))
//how refined you want your failures, that's up to you.
}
THERE'S NOTHING WRONG WITH FAILURE!
There, now that that got your attention, let me elaborate on the intention of these types.
Basically, they are a semantically richer way of expressing common failures when developing backend-servers.
Furthermore, these exceptions being part of the
of the application —by reading this file— you have not gauged their full potentiality, yet. The intention is to give richer interpretations to these "common failures" in othercore
module than could be done to the likes of Throwable.busymachines-commons
The reason why there is a trait FailureMessage, and some types that extend Exception is that the potentiality of these types can be achieved either through a monad stack approach to building applications, or to a more vanilla scala approach, respectively.
There are two quasi-parallel hierarchies of failures: I) the FailureMessage representing one single failure II) the FailureMessages representing a container of multiple FailureMessage. The intended use of the FailureMessages.id (and other ones inherited from FailureMessage is to signal the general "context" within which the specific FailureMessages.messages where gathered.
There are the following semantically meaningful exceptions (with their plural counterparts elided) that you ought to be using: - NotFoundFailure - SemanticFailures.NotFound - UnauthorizedFailure - SemanticFailures.Unauthorized - ForbiddenFailure - SemanticFailures.Forbidden - DeniedFailure - SemanticFailures.Denied - InvalidInputFailure - SemanticFailures.InvalidInput - ConflictFailure - SemanticFailures.Conflict
Each described in the SemanticFailures docs.
These definitions are also quite flexible enough to allow multiple styles of active development:
1) The quick and dirty, "better than RuntimeException" style. Basically, you just wind up using the default constructors on the companion object, or the companion object itself
This style should be kept just that, "quick and dirty". After the first iteration of the implementation these failures should be replaced by the ones in style 2)
2) The long term style. Where you subclass NotFoundFailure into a more meaningful exception specific to your problem domain, supply some context via the parameters, and assign it an (preferably) application-wide unique FailureID.
31 Jul 2017