On Thursday, 16 June 2022 at 13:54:52 UTC, Steven Schveighoffer
wrote:
[scope (success) lowered to finally]
[...]
Furthermore I always thought of scope guards as a means for
cleanup. Cleanup implies in my eyes removing things which have
been used in a previous task. This intended use is
On 6/16/22 6:07 AM, kdevel wrote:
On Wednesday, 15 June 2022 at 20:46:56 UTC, Steven Schveighoffer wrote:
[...]
It has not harmed my code though. I tried throwing inside a scope
guard, and it just works, I'm not sure why you can't throw in those?
You can but that is not acceptable for
On Thursday, 16 June 2022 at 11:38:40 UTC, kdevel wrote:
On Thursday, 16 June 2022 at 11:28:32 UTC, bauss wrote:
[...]
https://dlang.org/spec/statement.html#scope-guard-statement
Quote (again): "A [...] scope(success) statement may not exit
with a throw [...]."
[...]
If the spec forbids it,
On Thursday, 16 June 2022 at 11:28:32 UTC, bauss wrote:
[...]
https://dlang.org/spec/statement.html#scope-guard-statement
Quote (again): "A [...] scope(success) statement may not exit
with a throw [...]."
[...]
If the spec forbids it, but the compiler allows it, wouldn't it
then be a bug?
On Thursday, 16 June 2022 at 10:07:23 UTC, kdevel wrote:
On Wednesday, 15 June 2022 at 20:46:56 UTC, Steven
Schveighoffer wrote:
[...]
It has not harmed my code though. I tried throwing inside a
scope guard, and it just works, I'm not sure why you can't
throw in those?
You can but that
On Wednesday, 15 June 2022 at 20:46:56 UTC, Steven Schveighoffer
wrote:
[...]
It has not harmed my code though. I tried throwing inside a
scope guard, and it just works, I'm not sure why you can't
throw in those?
You can but that is not acceptable for the spec explicitly
forbids that:
On 6/15/22 3:51 PM, kdevel wrote:
On Wednesday, 15 June 2022 at 03:09:56 UTC, Steven Schveighoffer wrote:
I don't see what you see wrong with the code I wrote. It's
straightforward, obvious, and does the job I need it to do, in a way
that's not prone to future mistakes.
Sometimes it is not
On Wednesday, 15 June 2022 at 03:09:56 UTC, Steven Schveighoffer
wrote:
I don't see what you see wrong with the code I wrote. It's
straightforward, obvious, and does the job I need it to do, in
a way that's not prone to future mistakes.
Sometimes it is not easy to explain why code "feels"
I don't see what you see wrong with the code I wrote. It's
straightforward, obvious, and does the job I need it to do, in a way
that's not prone to future mistakes.
I explained why, but you don't agree with the explanation. That's OK, we
don't all have to write the same exact systems. D is a
On Monday, 13 June 2022 at 13:15:42 UTC, Steven Schveighoffer
wrote:
Possibly, but I don't close the handle. It goes back to a pool
to get reused.
Um. I need a (fresh) connection per CGI process. I wonder if
nowadays the TLS startup between the browser and the webserver
isn't at least one
On 6/13/22 9:15 AM, Steven Schveighoffer wrote:
Yes. If you don't execute the rollback and start executing more DB
calls, they all get included in the transaction (and might be expected
to be).
Should have said "might *not* be expected to be"
-Steve
On 6/12/22 4:11 PM, kdevel wrote:
On Tuesday, 7 June 2022 at 18:37:13 UTC, Steven Schveighoffer wrote:
[...]
My very common use of `scope(failure)` for my DB code:
```d
conn.exec("START TRANSACTION");
scope(success) conn.exec("COMMIT");
scope(failure) conn.exec("ROLLBACK");
```
Are there
On Sunday, 5 June 2022 at 23:57:19 UTC, Steven Schveighoffer
wrote:
On 6/5/22 6:09 PM, kdevel wrote:
On Sunday, 5 June 2022 at 20:53:32 UTC, Steven Schveighoffer
wrote:
[...]
For this purpose nobody needs a separate subclass named
`Error`. That works with `Exception`s.
You can use
On Tuesday, 7 June 2022 at 18:37:13 UTC, Steven Schveighoffer
wrote:
[...]
My very common use of `scope(failure)` for my DB code:
```d
conn.exec("START TRANSACTION");
scope(success) conn.exec("COMMIT");
scope(failure) conn.exec("ROLLBACK");
```
Are there multiple (successful) returns in your
On 6/7/22 3:58 PM, frame wrote:
On Tuesday, 7 June 2022 at 18:37:13 UTC, Steven Schveighoffer wrote:
My very common use of `scope(failure)` for my DB code:
```d
conn.exec("START TRANSACTION");
scope(success) conn.exec("COMMIT");
scope(failure) conn.exec("ROLLBACK");
```
This is hard to
On 6/7/22 12:58, frame wrote:
> ```d
> bool fun() {
> scope(failure) {
> // do something
> return false;
> }
>
> badCode();
> return true;
> }
> ```
>
> I know this is bad as I'm capturing a possible error here - but this is
> what an unexperienced
On Tuesday, 7 June 2022 at 18:37:13 UTC, Steven Schveighoffer
wrote:
My very common use of `scope(failure)` for my DB code:
```d
conn.exec("START TRANSACTION");
scope(success) conn.exec("COMMIT");
scope(failure) conn.exec("ROLLBACK");
```
This is hard to encapsulate into a type, as dtors
On 6/7/22 12:28 PM, frame wrote:
On Friday, 3 June 2022 at 23:40:50 UTC, Steven Schveighoffer wrote:
During the last beerconf, I wrote a short blog post about how `Error`
and `Exception` are different, and why you should never continue after
catching `Error`s.
I know the thematics but I
On Friday, 3 June 2022 at 23:40:50 UTC, Steven Schveighoffer
wrote:
During the last beerconf, I wrote a short blog post about how
`Error` and `Exception` are different, and why you should never
continue after catching `Error`s.
I know the thematics but I still wonder why we only have
On Monday, 6 June 2022 at 18:08:17 UTC, Ola Fosheim Grøstad wrote:
There is no reason for D to undercut users of @safe code.
(Wrong usage of the term «undercut», but you get the idea…)
On Monday, 6 June 2022 at 17:52:12 UTC, Steven Schveighoffer
wrote:
Then that's part of the algorithm. You can use an Exception,
and then handle the exception by calling the real sort. If in
the future, you decide that it can properly sort with that
improvement, you remove the Exception.
On 6/6/22 12:15 PM, Ola Fosheim Grøstad wrote:
On Monday, 6 June 2022 at 15:54:16 UTC, Steven Schveighoffer wrote:
If it's an expected part of the sorting algorithm that it *may fail to
sort*, then that's not an Error, that's an Exception.
No, it is not expected. Let me rewrite my answer to
On Monday, 6 June 2022 at 16:15:19 UTC, Ola Fosheim Grøstad wrote:
On Monday, 6 June 2022 at 15:54:16 UTC, Steven Schveighoffer
wrote:
If it's an expected part of the sorting algorithm that it *may
fail to sort*, then that's not an Error, that's an Exception.
No, it is not expected. Let me
On Monday, 6 June 2022 at 15:54:16 UTC, Steven Schveighoffer
wrote:
If it's an expected part of the sorting algorithm that it *may
fail to sort*, then that's not an Error, that's an Exception.
No, it is not expected. Let me rewrite my answer to Sebastiaan to
fit with the sort scenario:
For
On 6/6/22 12:59 AM, Ola Fosheim Grøstad wrote:
On Sunday, 5 June 2022 at 23:57:19 UTC, Steven Schveighoffer wrote:
It basically says "If this condition is false, this entire program is
invalid, and I don't know how to continue from here."
No, it says: this function failed to uphold this
On Monday, 6 June 2022 at 06:56:46 UTC, Ola Fosheim Grøstad wrote:
On Monday, 6 June 2022 at 06:14:59 UTC, Sebastiaan Koppe wrote:
Those are not places where you would put an assert.
The only place to put an assert is when *you* know there is no
recovery.
No, asserts are orthogonal to
On Monday, 6 June 2022 at 06:14:59 UTC, Sebastiaan Koppe wrote:
Those are not places where you would put an assert.
The only place to put an assert is when *you* know there is no
recovery.
No, asserts are orthogonal to recovery. They just specify the
assumed constraints in the
On Monday, 6 June 2022 at 04:59:05 UTC, Ola Fosheim Grøstad wrote:
For instance if a sort function fails, then you can call a
slower sort function.
Or in terms of actors/tasks: if one actor-solver fails
numerically, then you can recover and use a different
actor-solver.
Those are not
On Sunday, 5 June 2022 at 23:57:19 UTC, Steven Schveighoffer
wrote:
It basically says "If this condition is false, this entire
program is invalid, and I don't know how to continue from here."
No, it says: this function failed to uphold this invariant. You
can perfectly well recover if you
On 6/5/22 6:09 PM, kdevel wrote:
On Sunday, 5 June 2022 at 20:53:32 UTC, Steven Schveighoffer wrote:
[...]
For this purpose nobody needs a separate subclass named `Error`. That
works with `Exception`s.
You can use Exceptions instead. But the difference is they are part of
the program instead
On Sunday, 5 June 2022 at 21:08:11 UTC, Steven Schveighoffer
wrote:
[...]
Just FYI, this is a *different discussion* from whether Errors
should be recoverable.
The wording of this "question" bothers me really. What does
"Errors" mean here? If you mean thrown object having a (sub)type
of
On Sunday, 5 June 2022 at 20:53:32 UTC, Steven Schveighoffer
wrote:
[...]
For this purpose nobody needs a separate subclass named
`Error`. That works with `Exception`s.
You can use Exceptions instead. But the difference is they are
part of the program instead of considered a check on the
On 6/5/22 11:03, kdevel wrote:
> On Sunday, 5 June 2022 at 17:04:49 UTC, Ali Çehreli wrote:
>> On 6/5/22 08:07, kdevel wrote:
> [...]
>> Like many other programmers who include me, Sean Parent may be right.[1]
>>
>> Other than being a trivial example to make a point, the code I've
>> shown may be
On Sunday, 5 June 2022 at 21:08:11 UTC, Steven Schveighoffer
wrote:
Just FYI, this is a *different discussion* from whether Errors
should be recoverable.
Ok, but do you a difference between being recoverable anywhere
and being recoverable at the exit-point of an execution unit like
an
On 6/5/22 12:27 PM, Ola Fosheim Grøstad wrote:
Ok, so I am a bit confused about what is Error and what is not…
According to core.exception there is wide array of runtime Errors:
```
RangeError
ArrayIndexError
ArraySliceError
AssertError
FinalizeError
OutOfMemoryError
On 6/5/22 8:45 AM, kdevel wrote:
On Sunday, 5 June 2022 at 01:43:06 UTC, Steven Schveighoffer wrote:
[...]
But you aren't perfect, and so maybe you make a mistake, and trigger
an Error. The compiler handles this unexpected condition by unwinding
the stack back to the main function, printing
On Sunday, 5 June 2022 at 17:04:49 UTC, Ali Çehreli wrote:
On 6/5/22 08:07, kdevel wrote:
[...]
Like many other programmers who include me, Sean Parent may be
right.[1]
Other than being a trivial example to make a point, the code
I've shown may be taking advantage of the "structure of
On Sunday, 5 June 2022 at 14:24:39 UTC, Ali Çehreli wrote:
void add(int i) {// <-- Both arrays always same size
a ~= i;
b ~= i * 10;
}
void foo() {
assert(a.length == b.length); // <-- Invariant check
// ...
}
Maybe it would help if we can agree that this assert
On 6/5/22 08:07, kdevel wrote:
> On Sunday, 5 June 2022 at 14:24:39 UTC, Ali Çehreli wrote:
> [...]
>> struct S {
>> int[] a;
>> int[] b;
>>
>> void add(int i) {// <-- Both arrays always same size
>> a ~= i;
>> b ~= i * 10;
>> }
>>
>> void foo() {
>> assert(a.length ==
Ok, so I am a bit confused about what is Error and what is not…
According to core.exception there is wide array of runtime Errors:
```
RangeError
ArrayIndexError
ArraySliceError
AssertError
FinalizeError
OutOfMemoryError
InvalidMemoryOperationError
ForkError
SwitchError
```
I am not sure that
On Sunday, 5 June 2022 at 15:07:13 UTC, kdevel wrote:
... I would refactor the code:
I really liked this one. The way it solves and at same time
restrict the "external access" with that struct of (a,b) makes
the code easier to maintain too.
Glad I keep lurking around this forum.
Matheus.
On Sunday, 5 June 2022 at 14:24:39 UTC, Ali Çehreli wrote:
[...]
struct S {
int[] a;
int[] b;
void add(int i) {// <-- Both arrays always same size
a ~= i;
b ~= i * 10;
}
void foo() {
assert(a.length == b.length); // <-- Invariant check
// ...
}
}
void main() {
On 6/5/22 04:43, kdevel wrote:
> On Sunday, 5 June 2022 at 00:40:26 UTC, Ali Çehreli wrote:
> [...]
>> Errors are thrown when the program is discovered to be in an invalid
>> state.
>
> The following program throws an `Error` in popFront:
>
> import std.range;
>
> void main ()
> {
>
On 6/4/22 23:31, Ola Fosheim Grøstad wrote:
> On Sunday, 5 June 2022 at 00:40:26 UTC, Ali Çehreli wrote:
>> Errors are thrown when the program is discovered to be in an invalid
>> state. We don't know what happened and when. For example, we don't
>> know whether the memory has been overwritten by
On Sunday, 5 June 2022 at 07:21:18 UTC, Ola Fosheim Grøstad wrote:
[...]
The reality is that software is layered. Faults at different
layers should have different consequences at the discretion of
a capable programmer.
+1
On Sunday, 5 June 2022 at 01:43:06 UTC, Steven Schveighoffer
wrote:
[...]
But you aren't perfect, and so maybe you make a mistake, and
trigger an Error. The compiler handles this unexpected
condition by unwinding the stack back to the main function,
printing the error and exiting, so you
On Sunday, 5 June 2022 at 00:40:26 UTC, Ali Çehreli wrote:
[...]
Errors are thrown when the program is discovered to be in an
invalid state.
The following program throws an `Error` in popFront:
import std.range;
void main ()
{
int [1] a;
auto q = a[1..$]; // line 6
On Sunday, 5 June 2022 at 11:13:48 UTC, Adam D Ruppe wrote:
On Sunday, 5 June 2022 at 10:38:44 UTC, Ola Fosheim Grøstad
wrote:
That is a workaround that makes other languages more
attractive.
It is what a lot of real world things do since it provides
additional layers of protection while
On Sunday, 5 June 2022 at 10:38:44 UTC, Ola Fosheim Grøstad wrote:
That is a workaround that makes other languages more attractive.
It is what a lot of real world things do since it provides
additional layers of protection while still being pretty easy to
use.
*Correctness **is**
On Sunday, 5 June 2022 at 00:18:43 UTC, Adam Ruppe wrote:
Run it in a separate process with minimum shared memory.
That is a workaround that makes other languages more attractive.
It does not work when I want to have 1000+ actors in my game
server (which at this point most likely will be
On Sunday, 5 June 2022 at 07:28:52 UTC, Sebastiaan Koppe wrote:
Go has panic. Other languages have similar constructs.
And recover.
So D will never be able to provide actors and provide fault
tolerance.
I guess it depends on the programmer.
But it isn’t if you cannot prevent Error from
On Sunday, 5 June 2022 at 07:21:18 UTC, Ola Fosheim Grøstad wrote:
You can make the same argument for an interpreter: if an assert
fails in the intrrpreter code then that could be a fault in the
interpreter therefore you should shut down all programs being
run by that interpreter.
Typo: if
On Sunday, 5 June 2022 at 06:31:42 UTC, Ola Fosheim Grøstad wrote:
On Sunday, 5 June 2022 at 00:40:26 UTC, Ali Çehreli wrote:
That is not very probable in 100% @safe code. You are basically
saying that D cannot compete with Go and other «safe» languages.
Go has panic. Other languages have
On Sunday, 5 June 2022 at 03:43:16 UTC, Paul Backus wrote:
See here:
https://bloomberg.github.io/bde-resources/pdfs/Contracts_Undefined_Behavior_and_Defensive_Programming.pdf
Not all software is banking applications. If an assert fails that
means that the program logic is wrong, not that the
On Sunday, 5 June 2022 at 00:40:26 UTC, Ali Çehreli wrote:
Errors are thrown when the program is discovered to be in an
invalid state. We don't know what happened and when. For
example, we don't know whether the memory has been overwritten
by some rogue code.
That is not very probable in
On Saturday, 4 June 2022 at 22:03:08 UTC, kdevel wrote:
On Saturday, 4 June 2022 at 14:05:14 UTC, Paul Backus wrote:
This is entirely a question of API design. If it should be the
caller's responsibility to check for some condition before
calling the function, then you can throw an `Error`
On 6/4/22 9:43 PM, Steven Schveighoffer wrote:
But I think you are still not supposed to continue execution. I'm not
sure what a compiler might assume at this point, and I unfortunately
can't find in the language specification where it states this. It might
not be in there at all, the spec is
On 6/4/22 6:56 PM, kdevel wrote:
On Saturday, 4 June 2022 at 16:55:31 UTC, Steven Schveighoffer wrote:
[...]
The point of an `Error` is that your code can assume it cannot happen.
If it does happen, the code is invalid.
According to my favorite dictionary "assume" means "take for granted"
On 6/4/22 10:17, Ola Fosheim Grøstad wrote:
> Why can't Error unwind the stack properly?
Errors are thrown when the program is discovered to be in an invalid
state. We don't know what happened and when. For example, we don't know
whether the memory has been overwritten by some rogue code. Or
On Saturday, 4 June 2022 at 22:31:38 UTC, Ola Fosheim Grøstad
wrote:
So what do you have to do to avoid having Errors thrown? How do
you make your task/handler fault tolerant in 100% @safe code?
Run it in a separate process with minimum shared memory.
On Saturday, 4 June 2022 at 16:55:31 UTC, Steven Schveighoffer
wrote:
[...]
The point of an `Error` is that your code can assume it cannot
happen. If it does happen, the code is invalid.
According to my favorite dictionary "assume" means "take for
granted" [1]. If `Error`s may happen how can
On Saturday, 4 June 2022 at 22:01:57 UTC, Steven Schveighoffer
wrote:
You shouldn't retry on Error, and you shouldn't actually have
any Errors thrown.
So what do you have to do to avoid having Errors thrown? How do
you make your task/handler fault tolerant in 100% @safe code?
On Saturday, 4 June 2022 at 14:05:14 UTC, Paul Backus wrote:
[...]
What does that mean? Am I `Error` blind?
Generally you do not need to subclass `Error` yourself. The
most common way of throwing an `Error` in user code is to use
`assert`, which (with default compiler flags) throws an
On 6/4/22 2:46 PM, Ola Fosheim Grøstad wrote:
On Saturday, 4 June 2022 at 18:32:48 UTC, Sebastiaan Koppe wrote:
Most wont throw a Error though. And typical services have canary
releases and rollback.
So you just fix it, which you have to do anyway.
I take it you mean manual rollback, but
On Saturday, 4 June 2022 at 18:32:48 UTC, Sebastiaan Koppe wrote:
Most wont throw a Error though. And typical services have
canary releases and rollback.
So you just fix it, which you have to do anyway.
I take it you mean manual rollback, but the key issue is that you
want to retry on
On Saturday, 4 June 2022 at 17:17:13 UTC, Ola Fosheim Grøstad
wrote:
Why can't Error unwind the stack properly?
It does normally, but it doesn't destruct objects when those are
in `nothrow` functions.
Nothrow functions don't throw, so have no cleanup.
You could argue it is strange that
On Saturday, 4 June 2022 at 16:55:50 UTC, Sebastiaan Koppe wrote:
The reasoning is simple: Error + nothrow will sidestep any RAII
you may have. Since you cannot know what potentially wasn't
destructed, the only safe course of action is to abandon ship.
Why can't Error unwind the stack
On Saturday, 4 June 2022 at 01:17:28 UTC, Steven Schveighoffer
wrote:
If a thread does not catch an error and end the program, that's
a defect in druntime I think. If it tries to rethrow the
exception in the main thread (oh, man I have to check... Yeah,
this is what it does), then it's
On 6/4/22 7:57 AM, kdevel wrote:
On Friday, 3 June 2022 at 23:40:50 UTC, Steven Schveighoffer wrote:
During the last beerconf, I wrote a short blog post about how `Error`
and `Exception` are different, and why you should never continue after
catching `Error`s.
Feedback welcome, I didn't
On Saturday, 4 June 2022 at 14:19:22 UTC, Ola Fosheim Grøstad
wrote:
Also, what it is the purpose of @safe if you have to kill all
threads? Such rigidity will just make Go look all the more
attractive for service providers!
I agree with this, but given the current semantics there is
nothing
On Saturday, 4 June 2022 at 01:17:28 UTC, Steven Schveighoffer
wrote:
I've thought in the past that throwing an error really should
not throw, but log the error (including the call stack), and
then exit without even attempting to unwind the stack. But code
at least expects an attempt to throw
On Saturday, 4 June 2022 at 11:57:32 UTC, kdevel wrote:
2. Since 2017 or so I have written some 10 KLOC of D, maybe
about two dozen
classes deriving from Exception. But I did not annotate any
of my methods or
function with "nothrow" nor did I author any class deriving
from `Error`.
On Friday, 3 June 2022 at 23:40:50 UTC, Steven Schveighoffer
wrote:
During the last beerconf, I wrote a short blog post about how
`Error` and `Exception` are different, and why you should never
continue after catching `Error`s.
Feedback welcome, I didn't announce here when I wrote it
because
On 6/3/22 18:17, Steven Schveighoffer wrote:
> If a thread does not catch an error and end the program
No, the thread dies and the main thread doesn't know anything about it.
Unless if std.concurrency is being used and the main thread looks for
and receives a LinkTerminated message. (If
On 6/3/22 8:44 PM, Ali Çehreli wrote:
One feedback I have is about non-main threads. Although everybody agrees
that Errors should not be caught, the main thread does so and prints the
useful output that you show in the article.
Yes, the one exception to the no-catch error rule is to print/log
On 6/3/22 16:40, Steven Schveighoffer wrote:
https://www.schveiguy.com/blog/2022/05/comparing-exceptions-and-errors-in-d/
Cool! I didn't know catching Errors behaves specially in unittest blocks
and contracts.
One feedback I have is about non-main threads. Although everybody agrees
that
76 matches
Mail list logo
