Hi,

Recently while I was reviewing some swift code, a colleague left me the impression that I am the one with the bad habits and these were learned while coding in D. I still think that I proposed some changes to avoid some bugs but I was told that I am focusing on defensive programming and that is a bad thing.

The first issue that I raised was this one:

func renderCell(item: AnyObject, index: Int) {
-        fatalError("renderCell has not been implemented")
+
}

where I proposed to make that method abstract or let's not remove the fatalError message because this method it should be never called.

The second issue was this:

+    init(dataSource: WUPTableDataSource) {
+
+        self.dataSource = dataSource
+        dataSource.tableView = tableView

where I asked what happens if someone passes a dataSource that has a tableView set. I this class, there were set some events bind to the view and it was unclear what happened in that case and I proposed to add an assert to check if dataSource.tableView is not set before we set it.

For both of these issues I was told that swift is not Java and if the situations that I described happens, you don't want to crash the user app, because this will make the user unhappy.

Those things are for me, good habits that I do when I am programming with D. What do you think? and if I had bad ideas with those issues, what I can do to improve my skills?

thanks,
Bogdan

On 5/07/2015 6:53 p.m., Szabo Bogdan wrote:
> Hi,
>
> Recently while I was reviewing some swift code, a colleague left me the
> impression that I am the one with the bad habits and these were learned
> while coding in D. I still think that I proposed some changes to avoid
> some bugs but I was told that I am focusing on defensive programming and
> that is a bad thing.
>
> The first issue that I raised was this one:
>
> func renderCell(item: AnyObject, index: Int) {
> -        fatalError("renderCell has not been implemented")
> +
> }
>
> where I proposed to make that method abstract or let's not remove the
> fatalError message because this method it should be never called.
>
> The second issue was this:
>
> +    init(dataSource: WUPTableDataSource) {
> +
> +        self.dataSource = dataSource
> +        dataSource.tableView = tableView
>
> where I asked what happens if someone passes a dataSource that has a
> tableView set. I this class, there were set some events bind to the view
> and it was unclear what happened in that case and I proposed to add an
> assert to check if dataSource.tableView is not set before we set it.
>
> For both of these issues I was told that swift is not Java and if the
> situations that I described happens, you don't want to crash the user
> app, because this will make the user unhappy.
>
> Those things are for me, good habits that I do when I am programming
> with D. What do you think? and if I had bad ideas with those issues,
> what I can do to improve my skills?
>
> thanks,
> Bogdan

Your collages are arguing that if they exist, they could be called and make program fail. Which is a valid point of view.

However, from a development point of view, you kinda want to know if they are being called.

I think you are arguing for slightly something different then to what you think.
I recommend arguing for a function that allows you to log during development in some form (maybe exceptions) to find where code paths are being used where you did not expect.

Another thought is defensive programming is _not_ a bad thing. Its an amazing thing really. It's great to do, to make sure an application does not get into an erroneous state. But you know what also is great? Failing gracefully. Not something most developers do.

Anyway just my thoughts on it.

On Sun, 05 Jul 2015 06:53:34 +0000, Szabo Bogdan wrote:

> For both of these issues I was told that swift is not Java and if the situations that I described happens, you don't want to crash the user app, because this will make the user unhappy.

i completely agree. it's way better to keep going and silently corrupt user data. i mean, well, nobody cares about corrupted data if a program is not crashed, right? happy users with invalid data will buy version 2, for sure.

On Sun, 05 Jul 2015 19:01:59 +1200, Rikki Cattermole wrote:

> Failing gracefully. Not something most developers do.

usually that is not related. i mean that if program entered invalid state, it may be too late to save user data. it may be even undesirable to do so, as the data may be already corrupted.

what the good program should do (i think) is storing "working log", so if it crashed, the log can be replayed from the last saved state, restoring all the work. maybe with the option that allows the log to be replayed partially, to avoid endless crashes.

besides, it will be possible to send the document and the log to developers, so they can reproduce the exact bug.

On 5/07/2015 9:32 p.m., ketmar wrote:
> On Sun, 05 Jul 2015 06:53:34 +0000, Szabo Bogdan wrote:
>
>> For both of these issues I was told that swift is not Java and if the
>> situations that I described happens, you don't want to crash the user
>> app, because this will make the user unhappy.
>
> i completely agree. it's way better to keep going and silently corrupt
> user data. i mean, well, nobody cares about corrupted data if a program
> is not crashed, right? happy users with invalid data will buy version 2,
> for sure.

Ahhh sarcastic ketmar, one of the best ketmar's selfs. Welcome back.
It was what I was saying anyway :)

On 5/07/2015 9:37 p.m., ketmar wrote:
> On Sun, 05 Jul 2015 19:01:59 +1200, Rikki Cattermole wrote:
>
>> Failing gracefully. Not something most developers do.
>
> usually that is not related. i mean that if program entered invalid
> state, it may be too late to save user data. it may be even undesirable
> to do so, as the data may be already corrupted.
>
> what the good program should do (i think) is storing "working log", so if
> it crashed, the log can be replayed from the last saved state, restoring
> all the work. maybe with the option that allows the log to be replayed
> partially, to avoid endless crashes.
>
> besides, it will be possible to send the document and the log to
> developers, so they can reproduce the exact bug.

Of course of course.
Valid options in failing gracefully include resetting the data and informing the user. Also giving them an option to send a bug report to the devs.
Point being, having it just fail on start each time is not a valid end result or something else awful.

On Sun, 05 Jul 2015 21:39:23 +1200, Rikki Cattermole wrote:

> Of course of course.
> Valid options in failing gracefully include resetting the data and
> informing the user. Also giving them an option to send a bug report to
> the devs.
> Point being, having it just fail on start each time is not a valid end
> result or something else awful.

ah, i see and i fully agree.

On Sunday, 5 July 2015 at 09:46:19 UTC, ketmar wrote:
> On Sun, 05 Jul 2015 21:39:23 +1200, Rikki Cattermole wrote:
>
>> Of course of course.
>> Valid options in failing gracefully include resetting the data and
>> informing the user. Also giving them an option to send a bug report to
>> the devs.
>> Point being, having it just fail on start each time is not a valid end
>> result or something else awful.
>
> ah, i see and i fully agree.

I think that if you really are scared if your installed app will crash because of some assert that you wrote, it means that you are not confident enough with your coding skills. I use asserts to remember me something that I am not allowed to do.

As a developer sometimes I say that I will do "this" and I will remember to use it like "that" and this is almost never happens. When you work in a big team, this NEVER happens and not because people are evil, because we forget things, and it's easy to make mistakes.

I use asserts to fail quick, during development. If you are afraid to make a program that not crashes you should not be a programmer. I bet that everyone would prefer to  have a program that crash for known reasons instead from some unknown, strange, science-fiction bug.

And if you are really afraid of asserts in your code you can disable them for the release build, but I personally would not do that.

Bogdan

On Sunday, 5 July 2015 at 06:53:36 UTC, Szabo Bogdan wrote:
> "you don't want to crash the user app, because this will make the user unhappy."


This type reasoning is always flawed. It's like saying that the Earth is flat.

http://p0nce.github.io/d-idioms/#Unrecoverable-vs-recoverable-errors