- Last 7 days
-
en.wikipedia.org en.wikipedia.org
-
The basic rule of thumb is: "I'm not aware of all types of security exploits. I must protect against those I do know of and then I must be proactive!".
-
- Mar 2021
-
github.com github.compry/pry1
-
you can use the wtf? command to display a few lines of the backtrace for the most recent exception
-
- Feb 2021
-
trailblazer.to trailblazer.to
-
the ability to “error out” when something goes wrong
-
If anything here did fail in “validate omniauth”, all other steps in the chain would be skipped as the flow would follow the path leading to the failure terminus.
-
Things could go wrong in two places here. First, the validation could fail if Github sends us data we don’t understand. Second, we might not know the user signing in, meaning the “find user” logic has to error-out
-
-
sobolevn.me sobolevn.me
-
Return None. That’s evil too! You either will end up with if something is not None: on almost every line and global pollution of your logic by type-checking conditionals, or will suffer from TypeError every day. Not a pleasant choice.
-
we also wrap them in Failure to solve the second problem: spotting potential exceptions is hard
-
So, the sad conclusion is: all problems must be resolved individually depending on a specific usage context. There’s no silver bullet to resolve all ZeroDivisionErrors once and for all. And again, I am not even covering complex IO flows with retry policies and expotential timeouts.
Tags
- difficult/hard problem
- the specific context is important
- easy to miss / not notice (attention)
- depends on use case / application
- error/exception handling: spotting potential exceptions is hard
- too many ifs: bad
- error/exception handling
- need to solve specific case/problems individually (there is no general solution)
- anticipating what could go wrong / error/exception cases
- sad/unfortunate conclusion
Annotators
URL
-
-
-
certainly I wouldn't want it to start telling me that I'm not catching these!
-
-
www.morozov.is www.morozov.is
-
Railway Oriented Programming is a way to gracefully handle errors in your application
-
-
dry-rb.org dry-rb.org
-
Monads provide an elegant way of handling errors, exceptions and chaining functions so that the code is much more understandable and has all the error handling, without all the ifs and elses.
-
-
jrsinclair.com jrsinclair.com
-
functionalprogramming.medium.com functionalprogramming.medium.com
-
en.wikipedia.org en.wikipedia.org
-
Maybe T can be understood as a "wrapping" type, wrapping the type T into a new type with built-in exception handling
-
Undefined values or operations are one particular problem that robust software should prepare for and handle gracefully.
-
-
blog.logrocket.com blog.logrocket.com
-
This style of error handling uses monadic behavior — a substitute way of handling errors.
-
-
stackoverflow.com stackoverflow.com
-
Personally, I prefer signalling an error for invalid values
-
-
-
You can rescue at the method level, but more likely you’d want to rescue at the statement level.
-
-
github.com github.com
-
Other filters will ignore blocks when given to them.
Would be better to raise an error if block isn't allowed/expected!
-
Note that it's perfectly fine to add errors during execution. Not all errors have to come from type checking or validation.
-
Inside the interaction, we could use #find instead of #find_by_id. That way we wouldn't need the #find_account! helper method in the controller because the error would bubble all the way up. However, you should try to avoid raising errors from interactions. If you do, you'll have to deal with raised exceptions as well as the validity of the outcome.
What they're referring to:
Account.find('invalid')
will raise an error butAccount.find_by(id: 'invalid')
will not.
-
- Dec 2020
-
thecodebarbarian.com thecodebarbarian.com
-
the best way to ensure you've handled all errors in your run() function is to use run().catch(). In other words, handle errors when calling the function as opposed to handling each individual error.
-
// The `.then(v => [null, v], err => [err, null])` pattern // lets you use array destructuring to get both the error and // the result
-
- Nov 2020
-
stackoverflow.com stackoverflow.com
-
yell() { echo "$0: $*" >&2; } die() { yell "$*"; exit 111; } try() { "$@" || die "cannot $*"; }
-
If you were to check the return status of every single command, your script would look like this:
Illustrates how much boilerplate set -e saves you from.
Update: Oops, if you read a comment further below, you learn that:
Actually the idiomatic code without
set -e
would be justmake || exit $?
True that.
-
- Sep 2020
-
javascript.info javascript.info
-
The "invisible try..catch" around the executor automatically catches the error and turns it into rejected promise.
-
-
github.com github.com
-
Re Object.keys(undefined), I think I'm ok with that failing. AFAIK it would also fail in React
-
I just don't know if Svelte should handle it, since #each also fails for undefined iterators.
-
-
-
.catch(error => download_count = error) // check for error in template
-
- Jul 2020
-
code-examples.net code-examples.net
-
JSON parsing is always pain in ass. If the input is not as expected it throws an error and crashes what you are doing. You can use the following tiny function to safely parse your input. It always turns an object even if the input is not valid or is already an object which is better for most cases.
It would be nicer if the parse method provided an option to do it safely and always fall back to returning an object instead of raising exception if it couldn't parse the input.
-
- May 2020
-
developer.mozilla.org developer.mozilla.orgPromise2
-
in the absence of an immediate need, it is simpler to leave out error handling until a final .catch() statement.
-
Handling a rejected promise too early has consequences further down the promise chain. Sometimes there is no choice, because an error must be handled immediately.
-
- Apr 2020
- Mar 2020
-
stackoverflow.com stackoverflow.com
-
To be just a bit polemic, your first instinct was not to do that. And you probably wouldn't think of that in your unit tests either (the holy grail of dynamic langs). So someday it would blow up at runtime, and THEN you'd add that safeguard.
-
I want to raise errors with more context
-
As many would guess: ... catch StandardError => e raise $! ... raises the same error referenced by $!, the same as simply calling: ... catch StandardError => e raise ... but probably not for the reasons one might think. In this case, the call to raise is NOT just raising the object in $!...it raises the result of $!.exception(nil), which in this case happens to be $!.
-
-
ruby-doc.org ruby-doc.org
-
It is recommended that a library should have one subclass of StandardError or RuntimeError and have specific exception types inherit from it. This allows the user to rescue a generic exception type to catch all exceptions the library may raise even if future versions of the library add new exception subclasses.
-
-
bugs.ruby-lang.org bugs.ruby-lang.org
-
matcher === exception or exception.cause && block[exception.cause]
Tags
Annotators
URL
-
-
stackoverflow.com stackoverflow.com
-
The pattern below has become exceptionally useful for me (pun intended). It's clean, can be easily modularized, and the errors are expressive. Within my class I define new errors that inherit from StandardError, and I raise them with messages (for example, the object associated with the error).
-
-
github.com github.com
- Dec 2019
- Mar 2019
-
www.thedevelopersconference.com.br www.thedevelopersconference.com.br
-
Você consegue visualizar a saúde da sua aplicação?
Ainda que aqui os tópicos da certificação não cubram exatamente esse assunto, monitorar a saúde de um sistema e suas aplicações é missão do profissional DevOps. Atente para os tópicos:
701 Software Engineering 701.1 Modern Software Development (weight: 6)
e
705.2 Log Management and Analysis (weight: 4)
-