Відео

O problema está entre o teclado e a tela do computador kkkkk

coff script hj ta quentinho

KKKKKKKKKKKKKK CARALHO dei boas risadas com seus comentários, ta mandando bem nos vídeos mano

posso gritar agora?

se try/catch é ruim, então como fica o tratamento de excessões?

oque vc acha sobre Assembly no mercado?

O artigo muito taxativo e bom pra pegar dev junior que gosta de hype. Mais um artigo no Medium que busca polemizar. O autor apresenta exemplos baseados em TypeScript. Nesses tipos de linguagem, devido a liberdade da fazer como você quiser, cabe ao programador tomar os seus devidos cuidados. Esse artigo, assim como video, só leva em consideração o mundo da sua linguagem e esse é um detalhe muito importante. Tenta fazer uma requisição web no Java pra ver se ele não te obrigar a usar um try-catch ou um throws na assinatura do método caso o caller vá tratar a exceção. Tem linguagem que não tem pra onde correr. E isso bom na minha opinião. Deixa na mão de um cara iniciante sem supervisão a decisão de como tratar a exceção, logo logo você vai ver o cara fazendo uma requisição sem tratamento de erro ou try catch, ai na primeira coisinha pipoca tudo.

Acho que o termo que traduz bem em pt-br é Tecnicista e ele existe, é bem comum em software houses!

Acho que tudo e balanca... nao sou faaaazaaaasssso do try catch mas vc poderiater um try catch e um roll back no catch... agora try catch dntorde try catch dentry d try catch... isso e problema do dev e como ele esquerve o go horse dele, a feramenta e neutra e pode ser bem utilizada... tipo eu usando com um rollback em situacoes especificas.

Go vai tomar o mundo de assalto. RECEBA!

Tá aí um dos motivos de eu gostar tanto de Go - erros são valores e você é obrigado a tratá-los (além de que fica sempre explícito na declaração de uma função caso ela possa retornar um erro)

☕ noooooo

I don't uso CoffeScript Bacana o vídeo!

Ninguem entendeu o ponto central, não se trata de ser o melhor ou pior, ou condenar try/catch Se trata do ferramental que vai mitigar erros automaticamente, obvios que existem excelentes patterns pra usar com try/catch problema é garantir que os 500 devs numa empresa vao seguir isso Como ele disse, tanto quem ta fazendo, quanto quem ta revisando pode estar cansado e deixar, so vao descorbrir quando o cliente reclamar Sobre o pessoal falando que Go fica muito verboso pra sistemas enormes, na minha opniao nem deveria existir mais sistemas enormes, mesmo se for monolito poder ser feito com arquitetura modular e ddd justamente pra dividir ben o escopo e deixa facil de implementar e manter Pessoal nao percebe o proprio viés, facam como o Galelo e critiquem sua própria stack mesmo gastando e usando ela

qual o software do vídeo?

candies = [1, 2, 3] extraCandies = 1 setando esses parametros, a sua solução não vai errado não? vai somar 1 nesse 2 e vai dar igual ao max, dando True res = [False, True, True]

Try/Catch tem seus problemas, mas o título está muuuuiiito longe da realidade apresentada no video! O problema apresentado não é o Try/Catch, mas linguagens que "não obrigam" tratar o erro e/ou uso incorreto do recurso por parte do desenvolvedor. O exemplo do GO não é melhor pelas características internas da abordagem, mas só pq obriga a tratar (pelo menos o vídeo não demonstra outras vantagens relevantes) O que impede no Javascript do desenvolvedor só ignorar o tokenErr???? OU seja o "Result Pattern" aqui é tão ruim quanto o Try/Catch, pq o ponto não é Try/Catch ou "Result Pattern" e sim a linguagem que não obriga/força o tratamento e o uso incorreto. Nada é consertado no exemplo do Javascript ao trocar Try/Catch por "Result Pattern", pq é só o dev. ignorar o tokenErr que vamos ter problemas tbm. Em desenvolvimento tudo é um "trade off", ao usar por exemplo o "Javascript" vc ganha algumas facilidades e perde outras. Ao usar um "Java/C#/Go" vc ganha algumas e perde outras. Vale analisar o melhor custo/benefício para o projeto em questão. Ao ler o título achei que seria falado sobre as nuances do try/catch VS outra abordagem e não sobre como escrever código errado em linguagem que não "força" a escrever certo.

Parabéns pela dinâmica! Seria legal se fizessem uma em inglês pra quem está tentando vaga no exterior…

Tu é da banda de Recife (vi postando q tá morando na itália) ? Essa coral aí no braço...

Acredito que dar para resolver de uma forma mais simplificada, Usuário tem uma conta, com isso e possível controlar o número de acessos, como são dados leves e possível ter um servidor único para todo o mundo, dando possibilidade de acesso em qualquer lugar, a sessão e armazenada localmente e para acesso teria o log de IP + Nome da máquina, assim vai limitar o número de acessos mesmo sendo realizado no mesmo IP. Teria um LB ou um serviço tipo o Cloudflare para controlar o país ou estado que o usuário vai fazer o acesso, teria 1 servidor CND por pais ou estado com todos os vídeos armazenados, o banco de dados seria apenas para armazenar o caminho dos vídeos para não consumir o banco, usuário faz a requisição do vídeo, o LB decide de qual servidor buscar a informação, o vídeo e solicitado e neste momento vai fazer o Streaming do vídeo, precisa de um serviço para replicar os vídeos de vários servidores.

meu deus, esse video caiu como uma luva para mim kkk to começando a POO e try/catch é beem necessario , e to estudando python. mt obrigadaa

Aparentemente dev sênior na europa vive como alguém normal, já no Brasil se vive como rei, ganhando seus 15k trabalhando pro BR ou 20, 30, 40 mil trabalhando pra gringa então...

Legal o conteúdo! Quando trabalho com node, gosto de criar um adaptador de rotas (inverter a dependencia do express por ex) e colocar nele o trycatch. Depois crio classes de erros que eu gostaria de dar throw (BadRequest, NotFound, Conflict, etc...) e faço uma tratativa para enviar um body personalizado pro front. Dessa forma, se receber um erro 500 quer dizer que realmente deu merda, mas como eu tratei lá no route adapter, não vai bugar tudo

5:14, A velha pegadinha do strongly typed x dynamically typed. Python é FORTEMENTE e DINAMICAMENTE tipado. Sobre a forma de uso de try/catch isso é uma daquelas coisas que… depende dos cenários (como quase tudo em nossa área). Eu penso o contrário, exceptions não deveriam ser prioritariamente tratadas in-local (exceto se há uma boa razão para isso), até pelo fato de algumas vezes não fazer sentido (out of memory). Na maioria das vezes é melhor deixar propagar e deixar a camada mais acima tratar e lidar com esses erros, talvez tenha algum mecanismo ESPECIALIZADO na camada que trate os cenários de erros. Tentar tratar a maioria ou todas as exceptions no local onde elas ocorrem leva àquele local a ter mais ruído/sujeira de código, aumenta a complexidade, pois em alguns casos no tratamento haverá logging envolvido ou algum mecanismo de tracing e, consequentemente, importação de módulos e código que proveja essas funcionalidades causando aumento do grafo de DEPENDÊNCIAS não essenciais para aquela rotina. Além do ruído e distração causada, há também impacto no refactoring futuro devido às dependências. Propagando para cima é muito mais legível e possibilita uma estratégia muito mais modular e organizada/especializada. Um exemplo bem legal disso é o Django Rest Framework que nas classes de View tem um método onde você registra um manipulador especializado para tratar as exceptions que ocorrem nas chamadas daquele View set (pena que várias pessoas desconhecem). Quanto a forma que o Golang faz… well… sendo um programador de Go também, eu diria que há melhores formas de tratar erros. No final do dia, algumas dessas coisas depende muito da visão de cada sobre design. Desculpa o textão e bom vídeo! ;) P.S.: goto sendo considerado ruim não é consenso. Há cenários onde faz muito sentido do ponto de vista pragmático. Mas eu mesmo não uso (falando em C)

Quem tem problemas em usar try/catch tem que estudar mais sobre tratamentos de erros... Javascript pode até não ser a melhor linguagem, mas tem formas simples de tratar todos os erros. Não é um problema ter blocos try/catch um dentro do outro, mas é necessário fazer o tratamento correto e subir as exceções para o local onde serão processadas, fazendo isso não existe os problemas comentados no vídeo. Tem que saber como a linguagem lida com as exceções e tratá-las.

Mano se tivesse mencionado a questão do uso de memoria para manter a stack trace do erro quando ele é lançado nas camadas mais internas até faria sentido que vc ta falando. O código que vc mostrou tem tantos problemas que eu não acho que é culpa do try/catch kkk. Mas é muito bom o pattern do GO do either ou result.

Sem mencionar que sair do fluxo principal ou contexto principal é extremamente imperformático, sendo considerado uma má prática por algumas linguagens antigas. É preferível usar return true ou false. Linguagens como Go sanam isso utilizando erro em formato de variável sem sair do contexto ( main ).

assistindo o vídeo como se tivesse entendendo alguma coisa ( não entendi nada), mas sabendo que daqui um tempo vou voltar e entender tudo

assistindo

Essas avaliações de felicidade são realmente complicadas, a maioria das pessoas não é feliz e ponto. Escola, família, trabalho... As pessoas gostam mesmo é de reclamar. hehehe No Brasil era assim, aqui em portugal é Igual.

massaa

Obrigadaa

Putz mas aí usando assim, é ruim mesmo. Agora se souber usar, vc padroniza o erro, deixa mais rastreável, evita quebrar a API exceto quando é necessário, e sem 'mascarar' os erros também. Como dizia o grande poeta, "modéstia a parte, código ruim, eu sei fazer muito bem, em em qualquer linguagem, e com qualquer paradigma..."

Se o time responsável por me contratar não sabe ler meu currículo em inglês, perfeito! Já descarto um lugar que nem quero trabalhar. Inglês pra mim é essencial, igual nas vagas arrombadas que pedem inglês dentro do Brasil, eu tb sou candidato arrombado kkk

Caralho fechei quando ele disse não saber de Zephyr e tirar sarro.... Zephyr para embarcado é o futuro irmão.

Só porque eu queria .Net + Angular ; Agora fiquei na dúvida em qual stack escolher para ser fullstack

Por isso que a programação é fantástica, e esse tipo de vídeo é muito bom para nós vermos isso. Há muitas, e muitas formas de resolver um problema.

Poh mano... Tanto o exemplo péssimo de try/catch como o exemplo de solução de uso, são em TS/JS, o que me leva a conclusão, o problema é o noob que escreve igual o exemplo 1 e não a linguagem em si. não importa qual linguagem, se o carra escrever no go horse vai ser ruim de ler de qualquer jeito....

Os argumentos do vídeo estão corretos, porém incompletos (existem ainda mais motivos pq o try catch é ruim). O próprio fato das exceptions serem tratadas dessa forma torna ainda mais difícil de diferenciar quais erros devem ser tratados pela aplicação (erros recuperáveis), dos erros de lógica e bugs (erros irrecuperáveis). E sim, um programador experiente consegue diferenciar e implementar de forma correta, porém, á própria linguagem de programação não o deveria induzir a cometer este tipo de engano. Por isso, eu até argumento que o try catch deveria ser considerado uma feature ruim no design de uma linguagem de programação. Fun fact: um requerimento para ter o try catch é possuir um mecanismo de "unwinding" (_desenrolar_ call stack) o que além de ser difícil de implementar, em linguagens compiladas (Rust, se não me engano, isso acontece no C++ também), o compilador é impossibilitado de fazer algumas otimizações, já é necessário considerar que em "qualquer ponto" a execução pode ser interrompida. Artigo: Unwind considered harmful

Meu pai amado um dia me perguntei oq era coffee script e nunca mais quis saber, mano queria aprender Rust, mas não sei pq não gosto, mesmo gostando de tipagem

BucetaPattern faz voce escrever um codigo maravilhosooo

Um dos poucos vídeos que discordo fortemente do galego, esse pattern de result ofusca completamente a stack trace quando um erro acontecer, citando java, tenho a sensação que é como fazer try catch pra lidar com erros ao invés de exceptions Linguagens que já tem algo parecido nativamente ok, como go e rust, mas se não, vejo a aplicação como uma muleta pra uma certa incapacidade de algum sênior em transmitir o conhecimento necessário de estrutura de dados aos mais novos

Gosto do Canal e da simpatia do Augusto. Mas discordo fortemente do vídeo, foram exemplos pobres e mau utilizados de métodos e responsabilidades que jamais seriam implementados em uma aplicação minimamente inteligente e que siga algum padrão. Uma linguagem fortemente tipada com usos de tratamentos de erros: trycatch; Minimamente inteligentes seriam de fácil legibilidade e com carregamento de responsabilidade correta, criando uma via ou saída para cada situação necessária. A questão de escopo, simplesmente não existe. O erro está na abstração da arquitetura do projeto e no local de tratativa dos casos excepcionais.

A forma de try-catch em Java é da mesma forma q em python?

A desculpa é que trabalha cansado? kkk Foi mal, desce não. Se você precisa de uma linguagem para não "te deixar mentir", como você disse, o problema é com você. De toda maneira, se você programa porcamente, seu código será ruim, independente da linguagem. Como resolve isso? Escrevendo testes bem feitos. Isso, sim, vai pegar todos os erros e não deixar você subir código mal escrito para produção.

Pior do que usar try catch é não usar. Tem programador que se preocupa tanto com a qualidade do código que entrega que até esquece do software que está fazendo.

Toda provocação é válida quando o objetivo é evoluir. Mas sendo bem sincero, houve algus equívocos mais relacionados ao entendimento dos padrões da linguagem do que com o try/catch em si. Desde aninhamentos de try/catches sem um controle de escopo adequado, confusão com tipagem (python tem tipagem forte e dinâmica, inclusive) ou mesmo try/catch só mascarando erro ao invés de tratá-lo. Comparar alguns recursos de uma linguagem compilada com uma linguagem interpretada é como comparar laranjas e maçãs. Dá pra discutir trade-offs e usar isso pra melhorias na linguagem (tipo o type hint do python ou o typescript, meio que feitos para se aproximar de tipagem estática que você elogiou, por exemplo), mas usar uma amostra de código dificulta a discussão e não ajuda a entender o todo. Não subestime a capacidade de um dev cansado de fazer caquinha em Go também. kkkkkk

no java se vc tenta fazer isso ai ele vai te bate pq ele te obriga a sempre retornar então o caso do finaly sem retorno não aconteceria mais tem como burla tbm e tem como lança exceptions misteriozas é só usa RuntimeException. No fim se vc quiser fazer merda vc vai achar um jeito

sabe mt

queria q tivessem botado zig