so...a language design question about exceptions

1. Most modern advice considers exceptions to be a bad idea because you don't know which function can throw an exception, so you often end up wrapping tons of code in try-catch statements to be safe

2. There are two ways to "declare" an exception (or something that went wrong): in your return type, or in the method signature. Rust, for example, does the former (with Result<>) types, while Java does the latter (with checked exceptions)

3. These both have a large problem: What if there's an interface with a method getFoo() that returns a "T". However, your implementation wants to get the Foo over the network (or via a file). This means you'd need to return a Result<T> (or declare it on the method signature). Neither of these are possible because the interface doesn't declare it

...Is there any way around this problem?

I was wondering whether the post on r/ProgrammingLanguage inspired this question, and sure enough you answered it :P

yep :)

I spent all night thinking about it

I also read every answer on this post

I'm...actually a bit lost on this. I'm not getting what the issue is.

i dont know where to post it , but have you watched cgp grey's new video?

@betseg feel free to do so

@flawr It's true!

@El'endiaStarman How do you declare exceptions in a sane way?

I'm not even sure what "declare exceptions" means here.

aka, I need some mechanism to say, "This function will fail (if the file read fails)"

try haskell :D

however, this gets messy when dealing with interfaces. For example, it's common to have a Database abstracted behind a collection. You iterate over the list, and it'll actually perform a DB query

@flawr I've thought about FP, and it neatly avoids the problem by separating the two :)

@NathanMerrill actually there are two very prominent typeclasses like "Maybe" and "Either"

Oh, this is in strictly-typed languages.

yep :)

@flawr maybe and either doesn't solve the problem

it's the same issue as Result<>

because, lets say I want to implement an interface (not sure of the Haskell term for that) that only returns a T

I can't return a Maybe<T>

and what is the problem with that?

however, the usecase of wanting to return a Maybe<> is with Network/DB/File access, all of which are handled drastically differently in pure FP

but outside of the pure FP world, you still have this problem

where an interface defines a method to be implented

and your implemented method might fail

Well then I'd say the interface is crap:)

no, its not. You didn't define it

like a "List<>" interface

taht is why it is crap XD

its a list of items

do you really want a "throws DBAccessError" on that interface?

of course not, because only one of those implementations (the DBList) actually throws that error

or if I have a huge list that can't be stored in memory

so I save it to a file

and so I can get FileAccessErrors

so shouldn't this error/exception then be handled by the function your interface tells you to implement?

when trying to read it

@flawr and what should list.get(5) return if it errors?

if it's null, then you're basically swallowing an error, and you have this hidden edge case that the user doesn't know about.

if you throw a different (unchecked) error, then we have better error handling, but now we're back to square one: Any method can throw an error at any time

which makes reasoning about code hard

there's no good solution. I do think that FP solves it the best by separating the two

Ah now I think I understand the problem. Thanks for explaining so patiently

bah, in my head I wasn't being patient. I enjoy debating, so I was using a "loud voice" in my head.

(I wasn't impatient or anything, it was just funny to hear you say that)

anyways, the real reason I came in here was also to post a video

I found this humorous, and surprisingly enjoyable to watch

Well sometimes I'm just curious, and this is a topic I don't know a lot about, and when I'm the one asking the "stupid" questions I'm always grateful for people to discuss it with, especially if they do know a lot more about it!

I love discussing language design. I avidly follow the programminglanguages subreddit

and most people don't care :)

at least, in real live. Most programmers just code, and don't actually consider the language they are using

@NathanMerrill just subbed it

there's a lot of junk I don't care about: people advertising a language, or posting a link to some video or something. My favorite posts are definitely the discussion ones

@NathanMerrill That was fun to watch.

I'm currently watching Event 3: Fidget spinners

it's my favorite event so far

yeah, if you guys liked that first one try this one

I can't believe the how much stuff there is around these. Like certain teams have facebook page, there's a wiki on it

a fantasy league, a subreddit

@NathanMerrill I don't know why this is so nice to watch

...they have merch

gearbubble.com/gbstore/jelles