Total results: 175, showing 49 - 72

• nomnom/eternity 1.0.0

  
  Scheduled function execution, as a Component. With optional error reporting and and lock support.
  
• district0x/district-ui-web3-tx 1.0.13

  
  district UI module for handling web3 transactions
  
• democracyworks/resource-config 1.1.1

  
  Simple (too simple?) configuration handling
  
• dawcs/anomalies-tools 0.1.3

  
  Anomalies handling tools
  
• ez-database 2.0.0-alpha1

  
  Handling database queries with ease
  
• datreactor 0.0.1-alpha3

  
  Event and effect dispatch and handling (transactions/coordination) mechanisms for Cljc apps with DataScript databases
  
• fullcontact/full.time 0.9.0

  
  clj-time add-on for simplified ISO-8601 format date/time handling.
  
• spootnik/reporter 0.1.23

  
  error and event reporting component
  
• pager-duty-api 2.0

  
  The PagerDuty API provides programmatic access to entities within a PagerDuty account. It is designed around [RESTful principles](https://en.wikipedia.org/wiki/Representational_state_transfer) with a path structure based on resources and their relationships. All requests and responses are serialized in [JSON](https://en.wikipedia.org/wiki/JSON), including error responses. Schema are designed to be reusable across requests and across endpoints. More sophisticated API clients should treat PagerDuty resources as unique objects keyed by the `id` field that can be used in any API request involving resources of that type. Every resource contains a `type` field that identifies the schema it uses. ## Rate limiting Each account and authentication mechanism is limited to the number of API requests it can make every minute. API requests that exceed the API rate limit will return an [HTTP status code](error_codes.html#http_responses) of 429. Different requests may affect your rate limit differently, so clients should always be prepared to be rate limited and respond appropriately. ## Read-Only API Keys API requests made with read-only keys attempting to access endpoints with methods other than `GET` will return an [HTTP status code](error_codes.html#http_responses) of 403. ## Error Codes Most APIs will return an error code from an unsuccessful call. They are described [here](error_codes.html).
  
• clj-pretty-error 0.0.6

  
  Library to controll exception and stack traces for Clojure.
  
• pinpointer 0.1.1

  
  Pinpointer is yet another spec error reporter based on a precise error analysis
  
• nomnom/bunnicula.monitoring 2.1.1

  
  Monitoring middleware for Bunnicula, with built in support for StatsD metrics and error reporting to Rollbar
  
• dawcs/flow 4.0.0-pre5

  
  Functional style of errors handling (without monads)
  
• clojure-data 0.1.4

  
  Clojure-data is a simple, straightforward library for handling SQL, database connections, and data typing in Clojure
  
• adamrenklint/boot-test-cljs 1.1.0

  
  Boot task to run ClojureScript tests in Node.js, with minimal configuration, proper stacktraces and correct exit code on error or failure
  
• house.jux/http.server 2023.06.20

  
  Server with some request handling functionalities.
  
• merr 0.3.2

  
  Minimal and good enough error handling library for Clojure/ClojureScript
  
• helpful-loader 0.1.1

  
  Load resources with helpful error messages.
  
• ring-servlet-context 0.2.0-SNAPSHOT

  
  Ring middleware for handling servlet context path
  
• imintel/ring-xml 0.0.2

  
  Ring middleware for handling XML.
  
• babel-middleware 0.2.0-alpha

  
  A proof of concept library to rewrite error messages.
  
• clem-repl 0.1.6

  
  Repl Integration for Clem, the Clojure Error Mediator
  
• comporoute 0.2.0

  
  Composable request handling.
  
• akar/akar-exceptions 4.0.0

  
  First-class patterns for Clojure – Exception handling