exceptions

Type Members

1. abstract class ConflictFailure extends Failure with Conflict

   

   See scaladoc at top of file for general picture.

   See scaladoc at top of file for general picture.

   See SemanticFailures.Conflict for intended use.

2. abstract class ConflictFailures extends Failures with Conflict

   

   Plural counterpart of ConflictFailure

   Plural counterpart of ConflictFailure

   See scaladoc at top of file for general picture.

   See SemanticFailures.Conflict for intended use.

3. abstract class DeniedFailure extends Failure with Denied

   

   See scaladoc at top of file for general picture.

   See scaladoc at top of file for general picture.

   See SemanticFailures.Denied for intended use.

4. abstract class DeniedFailures extends Failures with Denied

   

   Plural counterpart of DeniedFailure

   Plural counterpart of DeniedFailure

   See scaladoc at top of file for general picture.

   See SemanticFailures.Denied for intended use.

5. abstract class Error extends Exception with FailureMessage

   

6. trait ErrorMessage extends FailureMessage

   

   THERE'S EVERYTHING WRONG WITH ERRORS!

   THERE'S EVERYTHING WRONG WITH ERRORS!

   The more meaningful design decisions are the ones made in failures.scala file detailing the definitions of various busymachines.core.exceptions.FailureMessage

   Since the types here are a minority, the design here emulates the one from the other more commonly used file.

7. abstract class Failure extends Exception with FailureMessage

   

   Should be extended sparingly outside of this file.

   Should be extended sparingly outside of this file.

   Most likely you need to extend one of the other cases.

8. trait FailureID extends AnyRef

   

   THERE'S NOTHING WRONG WITH FAILURE!

   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 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.

   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

   //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 {
     case object CannotBeDone extends FailureID { val name = "rd_001" }
     //... and many others
   }
   
   case class SolutionNotFoundFailure(problem: String) extends NotFoundFailure(
     s"Solution to problem $problem not found."
   ) {
     override def id: FailureID = RevolutionaryDomainFailures.CannotBeDone
   
     override def 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.
   }

   Since

   31 Jul 2017

9. trait FailureMessage extends AnyRef

   

10. trait FailureMessages extends FailureMessage

    

    FailureMessage counterpart, but for situations when multiple such messages can occur.

    FailureMessage counterpart, but for situations when multiple such messages can occur.

    FailureMessages#id, and FailureMessages#message should be used to convey the general context withing which FailureMessages#messages where gathered.

11. abstract class Failures extends Exception with FailureMessages

    

    Similar to Failure but encapsulate multiple causes.

    Similar to Failure but encapsulate multiple causes.

    Primarily used as containers for validation failures.

12. abstract class ForbiddenFailure extends Failure with Forbidden

    

    See scaladoc at top of file for general picture.

    See scaladoc at top of file for general picture.

    See SemanticFailures.Forbidden for intended use.

13. abstract class ForbiddenFailures extends Failures with Forbidden

    

    Plural counterpart of ForbiddenFailure

    Plural counterpart of ForbiddenFailure

    See scaladoc at top of file for general picture.

    See SemanticFailures.Forbidden for intended use.

14. abstract class InconsistentStateError extends Error with InconsistentState

    

    See SemanticErrors.InconsistentState for intended use.

15. abstract class InvalidInputFailure extends Failure with InvalidInput

    

    See scaladoc at top of file for general picture.

    See scaladoc at top of file for general picture.

    See SemanticFailures.InvalidInput for intended use.

16. abstract class InvalidInputFailures extends Failures with InvalidInput

    

    Plural counterpart of InvalidInputFailure

    Plural counterpart of InvalidInputFailure

    See scaladoc at top of file for general picture.

    See SemanticFailures.InvalidInput for intended use.

17. abstract class NotFoundFailure extends Failure with NotFound

    

    See scaladoc at top of file for general picture.

    See scaladoc at top of file for general picture.

    See SemanticFailures.NotFound for intended use.

18. abstract class NotFoundFailures extends Failures with NotFound

    

    Plural counterpart of NotFoundFailure

    Plural counterpart of NotFoundFailure

    See scaladoc at top of file for general picture.

    See SemanticFailures.NotFound for intended use.

19. abstract class UnauthorizedFailure extends Failure with Unauthorized

    

    See scaladoc at top of file for general picture.

    See scaladoc at top of file for general picture.

    See SemanticFailures.Unauthorized for intended use.

20. abstract class UnauthorizedFailures extends Failures with Unauthorized

    

    Plural counterpart of UnauthorizedFailure

    Plural counterpart of UnauthorizedFailure

    See scaladoc at top of file for general picture.

    See SemanticFailures.Unauthorized for intended use.